Unit test code coverage in PHP
So we all know grown-up development projects need unit testing, and lots of it. In the LAMP world PHPUnit is almost the de-facto solution, with xUnit heritage to make people mumble supportively about best practices and cross-domain expertise (currently working in a Java-heavy environment).
Perhaps less known is the automation of code coverage analysis. Thanks to one of the several gems xdebug has to offer, this can be integrated into the unit testing fairly easily. Watch your versioning though, we had to pull newer ones than CentOs 5.3 had to offer.
Simple Usage
The configuration / command line arguments are fairly key but something like:
$ phpunit —coverage-html ~/workspace/project/tests/coverage \
—colors —verbose ~/workspace/project/
With any use of external libraries (eg PEAR) we found it necessary to exclude those directories (eg /usr/share/) explicitly else coverage of those libraries was generated too, which is hardly the point. Beware also of symlinks confusing it a little.
The output, though a bit oldschool, is easy enough to drill down into, and seeing red lights turn to green is a surprisingly good motivation for developers to add more test, or better still, think about exactly what isn’t being tested fully.
Static Code Analysis
Also worth mentioning while we’re there is one of the static code analysis tools: at work I’ve set up phpcs with some luck. Its tab support is far from perfect (a tab, apparently, is a fixed amount of spaces that you’ve forgotten to convert) but other than that it can have its uses, and great for enforcing coding standards in a larger dev team.
nick wrote 267 words on Aug. 30, 2010 at 6:17 p.m.
Seven comments.
Paris escort girls wrote: March 29, 2012, 4:41 p.m. loose weight wrote: April 1, 2012, 6:15 a.m. мебель из сосны wrote: April 16, 2012, 7:27 p.m. Weight loss wrote: April 23, 2012, 9:56 a.m. Photomaster wrote: April 30, 2012, 9:18 a.m. private guide in Saint-Petersburg wrote: May 10, 2012, 1:22 p.m. Paris escort wrote: Yesterday, 9:23 p.m.