I spent a week testing the security framework at Mint. I chose Mock objects as the methodology for testing because I wanted to test …
I spent a week testing the security framework at Mint. I chose Mock objects as the methodology for testing because I wanted to test that when a user logs in a certain set of methods is called (i.e. there was clearly an expected behavior I was aiming to test). Being very familiar with the architecture of the code base I knew the levels of hierarchy that needed to be traversed for a user to successfully log in, and thus my test case consisted of verifying the correct behavior at each of those levels. While I was able to successfully use Mocks to create the test suite I wanted, I came across several key trade-offs of behavioral testing using Mocks.
1. You must have a decent understand of the use case you are testing; you must know which methods and classes are pivotal to the test case, and which can be abstracted away using expectations.
2. Using expectations can be a time-saver because unlike stubs you can just specify what the return value of the method should be, how many times it should be called, and what if any parameters are expected. This limits the amount of test code you need to write. However, the class methods need to be fairly deterministic, meaning they must always return the same result given a certain set of inputs.
3. Mocks are perfect when it comes to testing classes with limited functionality or that are isolated from other classes. Interdependencies between classes makes using Mocks a nuisance. If the given class you are testing has a lot of dependencies amongst other classes then it requires you to create Mocks for those classes as well. This can bloat your test code, and take a longer time to test, because now you must program for the dependent classes and setup their expected behavior as well.
