This article is part of the Continuous Integration, Delivery and Deployment series.
In the previous article we explored unit tests as the first and fastest set of tests we should run. Now it’s time to see whether our unit tests provide enough code coverage.
Unit tests by themselves do not provide enough confidence unless we know that they cover significant code coverage. Having all tests successful while, for example, covering only 15% of the code cannot provide enough trust.
Mature teams might not need to measure code coverage. They might know from experience that their unit tests are covering as much code as the project they’re working on needs. Teams like that tend to have years of practice with Test-driven development (TDD). However, for the majority of us, tools that measure the coverage are very indeed useful addition to our tool-belt.
A typical waterfall project has well defined phases that go from the idea conception until putting the solution in production, being the most typical of them:
- Requirements gathering
- Design of the solution / Architecture
- Testing phase (including all kinds of tests)
- User Acceptance Test
- Go Live (put in production)
- Post Go-Live support
It’s very common in big companies that there’s a functional team responsible for each phase. Thus, we get:
- Business Analysts to gather requirements
- Architects, Systems Engineers or Software Analysts to design the solutions
- Programmers or coders to implement it
- Quality Testers or Quality Assurance engineers to check its quality
- The customer to test the delivered solution
However, one of the big problems from this approach is that usually these teams work in silos. The right hand doesn’t know what the left hand is doing and this causes inefficiencies. To make it worse, sometimes the way to try to reduce silos is through an immense increase in bureaucracy, forcing teams to communicate through documentation.
When moving from the traditional waterfall process with manual testing towards BDD with automated execution of scenarios, one of the often asked questions is “how do you measure your test coverage?”. What it really wants to say is “we have high test coverage with manual testing, can you guarantee the same or more with the BDD?”. From there on usually comes the suggestion to transfer one-to-one manual tests to the BDD format. That’s not a good idea since the result would be less than adequate transformation to the different format without any tangible change. BDD is not only about automation but about the way we construct and deliver software.
Code Coverage Analysis
Main usages of code coverage analysis is to:
- Find areas of software under test that were not exercised by a set of test cases.
- Help in creation of additional test cases to increase the coverage.
- Provide quantitative measure of test coverage as indirect measure of quality.
- Identify redundant test cases that do not increase coverage
- Identify parts of the code that is not in use