A Farewell To Mocks

One aspect of TDD I will probably avoid in 2018 is extensive use of mocks. It is a well-known pattern among Go programmers to provide interfaces for key bits of functionality, and then devising mock implementations to enable a portable testing environment.

Some reasons for avoiding this pattern from this point forward:

• Mocks ended up not helping. My mock interfaces were typically not a precise representation of the real resource being substituted, so satisfying the mock interface ended up not being useful. My test coverage increased but there was no increase in real quality.
• A Maintenance Hassle. Some of my mock interfaces were so detailed and convoluted that they ended up creating technical debt on their own, despite not providing any meaningful value.
• Drift. Since the mock interface is not strictly associated with the real resource being substituted, there is no pressure to keep the mock interface in sync.
• This Code Isn't Open Source One of the key benefits of a mock interface is to ship a useful test to someone who has nothing more available than the code you have written. In my case, this is private business software which will never be relevant to anyone outside of our enterprise.

What's the alternative? Better crafted test environments. In our enterprise, that means Docker Compose. While Compose isn't perfect, it does let us build up a full environment in a portable fashion. The Compose environment carries with it it's own maintenance costs, but it is worth it to test against real databases, caches, orchestration tools, etc.

last update 2018-01-01