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.
</testsuites> <filter> <whitelist processUncoveredFilesFromWhitelist="true"> <directory suffix=".php">inc</directory> <file>./functions.php</file> <exclude> <!-- Don't include coverage of long for tests --> <!-- We test those by testing the supporting LMS framework --> <file>inc/long-form-tests/class-DAT_LongFormQuiz_Controller.php</file> <file>inc/long-form-tests/class-DAT_View_FrontLongFormTest.php</file> <file>inc/dat-ld-statistics/DatQuiz_Controller_Statistics.php</file> <file>inc/dat-ld-statistics/DatQuiz_Controller_Statistics.php</file> <file>inc/long-form-tests/class-DAT_Quiz_Stub.php</file> <!-- Ignore RCP Stripe Class, it is primarily a View class which shouldn't be tested --> <file>inc/class-rcp-payment-gateway-stripe-dat.php</file> </exclude> </whitelist> </filter> <logging> <log type="coverage-html" target="./tests/report" lowUpperBound="35" highLowerBound="65"/> </logging> </phpunit>
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 🙂
Build tests, check code coverage, make adjustments, repeat.
Entropy is the default, as you add features to/modify your code is very likely that your code coverage will decrease as new code is added.
But the code coverage reports give a safety net to our safety net. Check in from time to time to see when your tests need some updating—and be sure to show off the improvements to your clients, they will appreciate it!