Agile in a Flash 51

Test Double Troubles – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #51)

> Inhibited refactoring

> Tool complexity

> Passing tests that indicate nothing

> Mocking the SUT

> Low readability

> Ambitious mock implementations

> Vendor dependency

--

Inhibited refactoring. Test doubles exploit the linkages between classes, so refactoring class relationships may cause mock-based tests to fail.

Tool complexity. Mock tools have extensive APIs and can be idiosyncratic. It’s costly to understand both the tool and the code it produces.

Passing tests that indicate nothing. Fakes and stubs may not act quite like the classes they replace, leading to tests that pass and code that fails.

Mocking the SUT. Complex setup can bury the embarrassing fact that code we need to be real has been replaced with mock code, invalidating the test.

Low readability. Mock setup can be dense and idiomatic, making it difficult to see what’s really being tested.

Ambitious mock implementations. A fake is an alternative implementation of the class it replaces and can have bugs of its own. Keep your test doubles small and purposed to a single test or test fixture.

Vendor dependency. All third-party tools eventually fall out of favor, replaced with something newer and better. Don’t get stuck with yesterday’s tool.

To remedy most of these challenges, keep your use of mocks isolated and minimal. Refactor tests to emphasize abstraction and eliminate redundant mock detail.

--

“If you could kick the person in the pants for most of your trouble, you wouldn’t sit for a month.” ― Theodore Roosevelt