Last post I mentioned that there is a time and a place when you could consider writing a mock by hand.
It is my humble opinion, that there is only one situation that warrants handwritten mocks: Prototyping.
What do I mean by prototyping?
When you write an application, or even add a feature to an existing application, it’s always comforting to be able to start the “whole stack” and perform exploratory testing, as a developer. I mean, you. The person writing the code, starting the “whole stack”, and using the application, or new feature, in your developer environment. This is your chance to try out whether or not the application, or feature, will come up and be usable enough. Any realistic resource on test driven development (TDD) will acknowledge that there is a prototyping phase, at the beginning of a new project.
Now why am I sticking “whole stack” in quotes?
… to annoy you. No, just kidding.
In your application stack, there is almost always some external dependency, service, that you did not write. Often times, at least one of those is either a pain or too expensive for you to have locally. Expensive could be pure cost in money, as in your company can’t afford or won’t pay for more licenses, or it could be that your developer environment just cannot handle the load of the dependency. The dependency could also be a third-party service that you cannot access from your developer machine because of firewall restrictions, or again, someone is too cheap to pay for the extra access. The short of it: It’s not always possible to test end-to-end in the development environment.
So how do handwritten mocks help with this?
Basically, there should be an implementation of the external dependency’s interface that is an in-memory instance. It can either provide fixed values, values from a config, or actually mock the behavior of the external dependency. Ideally, such an implementation would be provided by the implementor of the actual dependency since they should know best how the actual dependency should behave, but not all providers are so kind. If this is the case, then writing your mock is not necessarily a terrible idea even though it defies the rule: Only mock your own objects.
So now can I test my mock?
Last post I mentioned that testing your mocks could indicate that you are doing something wrong, or even many things wrong. If you write a mock for prototyping, remember to include it with your source code, and not your test code. Source code should have tests when possible, and test code should be so simple that it never needs test code. This way you can maintain this rule: Never include something defined in test code in an assert.
Help! My external dependency is being hostile
Hostile Dependency is possibly one of my favorite terms. In a later post I will describe how forcing hostile dependencies to adapt will make it easy to swap out dependencies later.
