There is no magic in local codecoverage. XDebug and PHP_CodeCoverage libraries do their job. The tricky thing is remote codecoverage. We attach small script into application's front controller. When a special header is sent this script starts to collect coverage information. And in the end of tests, this data is merged, serialized and sent back to Codeception. So you can test and collect coverage report even on staging servers in real environment.

They also mention a few other updates in the release - new Redis and MongoDb modules, UX improvements and the normal bugfixes. You can find out more about the code coverage feature in their manual or just about the project in general from the main site.

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").

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).

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.

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.

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).

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.

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.

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!)

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.