Summary Pushing for test coverage is a bad incentive. It favors quantity over quality. You should prioritize your code with regard to test-worthiness. I discuss three such categories. First there is code that processes unmanaged and possibly malicious (user)input. You should test this for robustness. Secondly there is complex business logic with possible implementation errors. Test this for correctness. Thirdly there are quirks with trusted frameworks running code that doesn’t perform at scale. Run performance tests under realistic production loads to capture these.
I love reviews. When it comes to consumer equipment and whether it’s worth your money, it’s a blessing to have so much free advice to choose from. Last year I bought a new 3000-euro Casio Celviano digital piano online during the pandemic, purely based on internet reviews. Not my choice, but retail was locked down and I couldn’t try it out anywhere. Most reviews were favourable to raving, so I found safety in numbers there. Now you have to accept that reviews by retailers of their own wares are biased, but then again nobody would go to the trouble of a scathing review simply because they don’t like digital pianos, musical instruments in general or have it in for Casio as a company. Pianos are not controversial, in other words. What on earth does this have to do with code reviews? Bear with me.
There is plenty of opinions on how to do Test-Driven Development well. Today I want to discuss the drawbacks of the orthodox TDD school, let’s call it OTDD. Although as a development method it lacks a how-to bible like the Scrum Guide, some proponents defend their take with a religious level of conviction. To my understanding OTDD has the following characteristics:
You start by writing a failing test against a skeleton implementation. Then you dress it up by implementing the scenario, making the test pass. Test and production code evolve strictly in tandem, and you typically have a one-to-one relationship between a test suite and a source file, usually a class.
It follows then that all dependencies of a class under test must be set up using test doubles (spies, stubs or mocks). This applies not only to unmanaged, out-of-process dependencies like database, network and file handles, but also to any class in your own deliverable.