Code Coverage Reports for WPUnitTests

Introduction

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.

Setting up in phpunit.xml

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>

The Report

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.

Report dashboard

The hop over to the dashboardvia the link or directly the dashboard.html file. This is a much more informative and interesting report

Coverage and Risk

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 🙂

Our Strategy

  1. Calling code CRAP is an obvious ruse to get your attention. Take the bait and focus on these for building out tests. If you find these chunks of code untestable –then they’re prime candidates for refactoring.
  2. Next, look at the insufficient coverage charts. Are there classes/ methods in there that you know to be critical the core logicRemember, these reports are just a guide, you know your code best. of your custom plugin? If so, add some test coverage, this is where you want to build your safety net.
  3. Finally, is the code coverage report pitching a fit over something you have no intention of building out tests for?e.g. a file the does templating with minimal/ no logic in it Go back to your phpunit.xml file and add an exclude tag to your filter along with a comment on why you’re doing that, it’ll clear out false alerts make your coverage report more informative

Conclusion

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!

×

Keyboard shortcuts

CTRL+Shift+F Search slideshow
F Fullscreen view
CTRL+Click Zoom in
Esc Topic overview
Right arrow,
Down arrow
Next slide
Left arrow,
Up arrow
Previous slide

Color codes

Tooltip
Hover over text more additional info
Link to an external resource
Link to an internal slide
If buttons aren't working, click in the screen to "focus" your browser
RSS
LinkedIn
Share