Mapping a test to the classes, methods, even lines that it executed … that has to be my favorite new feature in Clover2. This is called per-test coverage in Clover2, and helps answer the following questions:
“Which tests cover class X?”
Many projects dutifully begin following a test-naming convention such as XTestCase.testYYY. This convention falls apart quicker than it takes you to google “Behavior Driven Development“, or as soon as you have to write a regression test for a bug you just found.
Every line of source code has the following pop-up in a Clover2 report:
The popup displays a table of the tests which entered the get method. The table contains the following sortable columns:
- Test-Contribution: how much of this class’s coverage is attributed to that test – showing which tests are the biggest contributors to the coverage.
- Test Name: the name of the test and links to the test source code and to the test result summary page.
- Result: whether the test passed or failed.
“How well tested is the code I’m about to change?”
Before jumping out of a plane, it’s good to know how well your parachute is packed.
Changing code always involves taking some risks. It’s re-assuring to be able to estimate what that risk is and how best to reduce it. Being able to view which unit tests exercise the code to be changed helps in doing this. Most importantly, to see immediately whether or not a test case already exists that specifically tests that code. If not, it’s handy to see which module of your test suite is the best to add the new test case to.
“How did this bug escape our unit tests?”
When a bug is found in Clover, my first re-action is to ask the question: “Which unit test didn’t discover that?”. Being able to go from the location of the bug in the source view, to each of the tests which covered the buggy line, method or class is something I’ve not been able to do without Clover2.
On large or unfamiliar projects, finding the best spot to add a unit test is sometimes a daunting task. Its often tempting to simply add a brand new test. The reasons against this are:
- You will not know if one of your existing tests is broken i.e. it passes when it should in fact fail
- The new test may ‘overlap’ i.e. performs the same test/check as another test. This adds to the burden of maintaining tests.
Writing the test to reproduce a bug becomes much less of a task once you are already looking at a Test Class which tests code near to that containing the bug.
Go both ways.
Clover2 reports provide new insight into your project’s tests which was previously not possible. This helps boost code quality by:
- encouraging new tests to be written;
- reducing the possibility of test overlap, and
- giving you confidence to refactor knowing that your tests are solid.