What should we do to start mocking?
In the most simple case, we extract the interface from the functionality we want to mock and prepare another implementation that returns mock results. Unfortunately, there are few problems: first, this code may be the legacy one (so there’s no chance for any change in code) and second, preparing full mock implementation may take a lot of time (that doesn’t make much sense, if you just need 1 method mocked - but it’s a different method in each unit test). Of course we have to provide the way to call our implementation instead of original one - that usually means that original code and unit test code will have a different “executing layer” (what means that our test code doesn’t really test what should be tested…). Introducing IoC container won’t solve it really.
The other approach is to use specialized mocking library. Majority of them are quite simple - they require extracted interface and they heavily use reflection. That unfortunately means they may be no use for legacy code. Isolator is quite different - it uses profiler API in execution time (like Microsoft Moles), so there’s no need for extracting interface. You can mock any code, including .NET framework assemblies classes.
How do we mock anything?
- mock every method call or just calls with specific parameters
- mock every method with parameters meeting custom criteria
- mock properties in the same way you can mock methods
- assert code call conditions (if something was or was not called, regardless of parameter values or for given parameter values)
- do pretty much all the same stuff from above with private methods / properties (API is different as they are not available directly for obvious reasons)
- swap all calls to fake with calls to some other instance
- decide on the way fake object is constructed (if original constructor should be called or not)
To Be Continued …