Part of:Unit testing best practices and frameworks
How to plan unit test coverage
Explore what an effective unit testing strategy looks like, whether it's wise to aim for a certain percentage of test coverage and how much unit testing is enough.
Regardless of the software methodology a development team uses, unit testing is a way to ensure a baseline level of quality with every build.
Some development teams discuss a unit testing strategy in terms of how much of the codebase unit tests cover. But just as counting lines of code does not necessarily determine development quality, a certain percentage of test code coverage does not necessarily determine test quality.
Learn what unit tests accomplish, how to plan unit test coverage for new and existing applications and the right way to direct code coverage for maximum benefit without excess effort.
What is unit testing?
Software teams may describe various testing types as unit testing. In some organizations, unit testing refers to story testing or, alternatively, when a QA professional validates a single feature. For this discussion, let's define unit testing as code-based and code-driven tests one writes alongside the functional code. Developers execute unit tests while coding. Additionally, a development team should collect all unit tests together as an automated test suite that runs whenever developers check new code into the main code repository or branch for the project.
Unit testing improves software quality with every code check-in and build. Unit tests are the fastest, most direct method to find and correct defects before they affect the main codebase. Even if a team has testers that execute additional functional, integration and regression testing, unit tests are essential to software quality. The earlier one catches a defect, the less rework it requires, which keeps costs down.
If a development team is starting a product from scratch, it's simple to include unit testing. Unit testing is difficult to do in an established codebase where the team didn't implement the practice from the start. Adding it is worth the effort, though, especially for high-priority and highly exercised sections of code. Unit tests also provide developer-level documentation of how the system works. Make unit tests part of the training to get developers up to speed on a codebase.
Unit testing code coverage
How much unit testing is enough? The amount of source code a suite of unit tests exercises is called its code coverage. It isn't realistic -- or necessary -- to expect 100% code coverage through unit tests. The unit tests a development team creates depends on business needs and the application or applications' complexity.
Granted, if a development team did achieve 100% unit testing coverage, it would have an extremely clean codebase and would have reduced any overly complex routines. But in real software development, 100% unit testing coverage never happens. For companies struggling to keep older code functional, it's too time-consuming to add unit tests to even high-priority, complex code. Companies can lose business due to defective, difficult-to-use applications, but developers also can waste time and money on excessive code coverage. Code coverage for an application is a return-on-investment decision.
For an extensive existing codebase, create unit test suites around these areas:
critical and high-priority functions;
functions that customers use; and
code that is frequently accessed.
This strategy for unit tests will keep essential workflows functioning smoothly so the application can succeed and grow.
It isn't realistic -- or necessary -- to expect 100% code coverage through unit tests. The unit tests you create depend on business needs and the application or applications' complexity.
Aim for 95% or higher coverage with unit tests for new application code. When developers unit test as they program, they improve the longevity and quality of the codebase. The time a development team invests in unit tests pays off with less time spent troubleshooting defects and analyzing problems later. And, with a suite of unit tests for regression testing, teams experience fewer instances when a new feature breaks the existing functionality.
Code coverage vs. code quality
Write unit tests for critical functions and heavily used customer workflows. Focus on building valid, prioritized unit tests -- not on a particular amount of code coverage. Defect detection in higher-priority code areas is goal number one.
Goal number two is to execute unit tests each time developers check in code and every time the team creates a new build. When developers use unit tests to prevent breaking changes in a branch, they can prevent rework and project delays. The focus should be on the validity, priority and frequent execution of unit tests ahead of any other measurement.
All software code benefits from unit testing, but that fact does not necessarily translate to a specific percentage of code covered. Invest in the application and add as much valid unit test coverage as is reasonable.
