In TDD and Code Coverage, we established that code coverage tools do not provide useful project metrics, in and of themselves. In TDD, we don’t use code coverage tools for this purpose because we don’t need to. If all production code is written to satisfy prewritten, failing tests, then by definition, all code is covered.
Still, we do have automated tools that can measure coverage. Are they useful to a TDD practitioner? Yes they are. Here are three things they are useful for.
- To ensure that all developers are following this process. In a shared code base, we watch code coverage to make sure it never goes down. If it does, we need to find out how and why the process wasn’t followed.
- Sometimes, developers put temporary code into the system to help them investigate, understand, or track something. This code should be removed once the investigation is done. If code coverage slips, there may be “dead code” that was left in the system.
- Sometimes, we determine that a test is no longer needed. It might be out of date or redundant. When we remove such tests, we examine code coverage before and after their removal. This confirms that we were right to delete them.
Strong tools are great, but we don’t want them to take over our process. We want to use them to support it.
This is Scott Bain. Visit us at www.netobjectives.com.