Building out automated tests for custom code has obvious benefits for the developers—but how do we show the benefits to a client? Outlining and demonstrating the ablilty to quickly test the custom developed components against new updates in the systemand reinforces our “integration testing” approach is a start. Explaining that it provides a baseline of teststhe expression “regression testing” is often expressive and accessible enough for this purpose that can be used when future features are added helps as well.
But the final icing on the cake is code coverage reports. These graphs, charts and percentages help show the client an objective outcome of the time and resources spent on developing and maintaining tests.
We’ve already done the hard work here with environment setup and configuring phpunit.xml. The logging tag is already generating coverage reportsfor the files listed in the <filter> tag in the target directory of the <log>If your config has multiple logs, it’s the one with type=’coverage-html’ tag. Let’s check it out.
Running your phpunit tests generates code coverage report files in your target directory. A jumping off point is the index.html—go ahead and open it in your favorite browser.
The hop over to the dashboardvia the link or directly the dashboard.html file. This is a much more informative and interesting report
You’ll see you’re provided with a set of charts for both Classes and Methods. One addressing code coverage, and one addressing project risks. The coverage chart will flag classes and methods, that are below the low lowUpperBound threshold as a percentage of lines covered.
The Project Risks chart is the really interesting one. On the x-axis is your code coverage. On the y-axis is a measure of the Cyclomatic complexity. Together, this calculates the Change Risk Anti-Patterns indexThat’s right, the coverage report just called your code CRAP—nothing personal, it does that to everyone 🙂