Place of Tests in Software Development
FleetingWriting a piece of software is like performing a constrained optimisation.
You look to write the minimum amount of code that fulfil its promises.
Here, I assume that you don’t want to spend time writing and maintaining useless code. Also, I suppose that if you don’t manage to explain how some piece of code relates to its purpose, then that code is not relevant. Therefore, you most likely want to remove the code that does not help you fulfil the promises of your software.
Following Occam’s razor, you’d rather write the simpler piece of code that you need. All other things being equal, there is no reason to prefer a more complicated code1.
To do so, you need to be clear about the commitments of your code and ensure that you review those at regular interval.
When you write tests, make sure those describe as clearly as possible the promise your software made, so that it will be as easy as possible to review it later.
Your primary focus should be whether or not the promises are fulfilled. Consider tests as being an instrumental objective that helps you in that primary focus.
Indicators, such as code coverage are often seen as a way of finding out pieces of code to test. To me, this leads to the unintended consequences of code coverage where you loose sight of the reason why your write this piece of code in the first place.
Instead, I recommend that you interpret the uncovered code as code to get rid of until proven otherwise.
There are two options facing some uncovered test.
- either it makes you realize that some promise was left implicit. In that case you need to add a test. But you should not use the code as a driver to write the promise or you will be anchored. You need to temporarily forget about this code and focus on the promise you forgot to make explicit.
- or you trust your promise coverage. Therefore try to get rid of that code.