Derick Rethans has a new post to his blog today talking about some work that's been done to speed up XDebug's code coverage generation. Changes in the coming 2.2 release have some improvements that make things perform better and put less stress on PHP in the process.

Code coverage tells you how much of your code base is actually being tested by your unit tests. It's a very useful feature, but sadly, it slows down PHP's execution quite a lot. One part of this slowdown is the overhead to record the information internally, but another part is because I have to overload lots of opcodes. (Opcodes are PHP's internal execution units, similar to assembler instructions) They are always overloaded even if code coverage is not used, because it's only safe to overload them for the whole request.

These changes were from a combination of contributions from Taavi Burns and a new ini setting that will allow you to enable or disable the code coverage in XDebug. Benchmarking shows a good amount of time reduction in coverage runs - dropping anywhere from a few seconds to over a minute. He also mentions the idea of "modes", shortcuts to predefined settings for different types of reporting (like "profiling" or "tracing").

Sebastian Bergmann has a new post to his blog talking about some of the future plans for better code coverage metrics for PHP applications (not just the statistics that we have now as generated from PHPUnit runs combined with Code_Coverage PEAR package and Xdebug).

Xdebug currently only supports what is usually referred to as Line Coverage. This software metric measures whether each executable line was executed. Based on the line coverage information provided by Xdebug, PHP_CodeCoverage also calculates the Function / Method Coverage software metric that measures whether each function or method has been invoked.

The various kinds of coverage they're planning the in future include statement coverage, branch coverage (boolean evaluation), call coverage, path coverage with an alternative of linear code sequence and jump coverage (LCSAJ).

Volker Dusch has a new post to his blog looking at handling segfaults during code coverage generation that might come up during your continuous integration process (with PHPUnit flavor unit tests).

About half the "Build failed" mails I've gotten from Jenkins in the last two weeks where not due to me breaking the tests but just PHPUnit segfaulting. "Wait! I know PHPUnit can't segfault!", only PHP itself can. And it does, quite often. For some reason that probably has to do with using PHP 5.2.OLD it doesn't survive generate the clover.xml file or the HTML report about 20% of the times it's being run.

He finds a solution to keep this from happening - not correcting the segfault as much as running the testing again to get it to pass. He wraps the call to PHPUnit inside of a simple shell script that tries to execute the PHPUnit testing suite as long as a segfault isn't thrown. If something was seriously broken, this could cause all sorts of problems, but in theory it's a simple hack that gets the job done.

Volker Dusch has a suggestion for all of those developers out there really concerned about the quality of your code - consider running your unit tests every time you save a file with the help of a tool called PyWatch.

At the moment he placed the Idea in my head that i want my testsuite to run every time a file changes anyway, let someone else figure out how that is triggered. Well, someone did figure that out, thank you. It's called "PyWatch" and is a simple python script that monitors files for changes and executes a script if one has changed.

Obviously you wouldn't want to keep this going for larger code bases (the potential for overlap is horrible) but it could be quite useful when doing test-driven development to save yourself some hassle at the outset. He includes the commands you'll need to get things running and a simple PHP script that points the PyWatch instance to the correct files.

A new announcement on the PHP.net site today talks about this year's TestFest, an even to help increase the code coverage of the tests on the PHP language itself.

During TestFest, PHP User Groups and individuals around the world organize local events where new tests are written and new contributors are introduced to PHP's testing suite. Last year was very successful with 887 tests submitted and a code coverage increase of 2.5%. This year we hope to do better.

The SVN repository and reporting tools are back again this year (a great improvement over years past) with the new additions of an automated test build environment and screencasts showing the tools in action. You can find out more about this year's event on the TestFest page of the PHP.net wiki (including finding an even near you to participate in).

In a new post to his blog Sebastian Bergmann talks about a new "dashboard view" that's been added to work with the PHPUnit testing suite - PHP_CodeCoverage. He talks more about what it has to offer:

PHP_CodeCoverage is a library that provides collection, processing, and rendering functionality for PHP code coverage information. Its architecture has support for multiple backends for collecting code coverage information (currently only support for Xdebug is implemented) and for reporting code coverage information (for instance using Clover XML or as an HTML report).

The dashboard shows the code's class coverage distribution, class complexity, top project risks and the least tested methods to help you narrow down potential issues in your application. Here's an example of the output.

As Sebastian Bergmann mentions in his latest post, he's changed up how the code coverage functionality is handled in PHPUnit so that he can add something new - CRAP.

PHP_CodeCoverage is a component that provides collection, processing, and rendering functionality for PHP code coverage information. [...] Having all code that deals with code coverage in a separate component allows for easier development and better testing. The first result of these improved development conditions is a small new feature that I recently implemented, the support for the CRAP metric.

Your code's CRAP (Change Risk Analysis and Predictions) scoring combines the idea of cyclomatic complexity and code coverage statistics to try to guess at how difficult any given piece of code would be to maintain. You can see an example here - the lower the number the better.

Zoe Slattery has posted an update about the TestFest events happening around the world and the contributions they've been making to the overall cause of getting PHP code coverage as complete as possible.

Groups from all over the world have contributed 554 new tests for PHP since April 1st 2009. Of these, 327 have already been moved into PHP's CVS (thanks Felipe!). The results of running tests on a Linux 32 bit platform can be seen here (sorry about the colour scheme), the user groups who have contributed are also listed. We also run the tests on a 64 bit Linux platform here, but this only runs PHP5.3 and PHP5.2.

She's also run some complete code coverage tests (after fighting a bit with ccache and lcov) and came up with a two percent increase overall (including a huge jump in the ext/ldap extension's coverage from about nine percent up to almost ninety percent!)

Greg Beaver has a new post reporting on his latest efforts to improve the Pyrus PEAR installer and to make it a more strong, stable and robust end result.

One of the problems I found when designing the new code for PEAR 1.4.0 (back in the day) was that it was very difficult to determine whether changes would break things. The main problem revolves around the colossal size of the test suite. [...] This is a real problem when trying to develop with any kind of flow. If, after every change, one needs to sit through 35 minutes of tests, one will never develop anything of substance.

What he wanted was an application that could detect only the files modified and tests those with the results put into the code coverage report. To fill the need, he created test-modified.php to run just the phpt tests needed.

According to this new post on the NetBeans blog, a new feature - code coverage support - has been added to the most recent version of the IDE.

After a few days, we would like to inform you that code coverage for PHP has been added to the NetBeans IDE. Thanks to PHPUnit (version 3.3 or newer required) we are able to provide code coverage for PHP files in a similar way as for Ruby or Python.

They give the step-by-step (screenshotted) process for running a coverage report on your current project and how to view which tests passed or failed validation.