PHPUnit, according to its PTS, has been in Debian since 2009. But it was orphaned, and nobody took care of it for a while. That is until few weeks ago, Luis Uribe started to work on it. Since he isn’t a DD, and that I take care of, I believe, about half of the all the PHP PEAR packages in Debian, I started working with him on re-doing the work of packaging PHPUnit for Debian. Previously, the old version was quite wrong, with missing dependencies, and not really working, what a shame…
PHPUnit 3.6 has been in Debian SID for 3 days now. And it’s working well. I’m now adding runs of unit testings from upstream packages at build time (of course, only if DEB_BUILD_OPTIONS doesn’t contains “nocheck”, as per the policy). All together, it’s been quite some fun to hack this, and I’m quite happy of the results, even though there’s still a lot of work remaining.
PHP itself is running unit tests at build time. And not just a few: more than 11000 of them. The only “small” issue, is that they are totally outdated. Over the time, the vardump() function has evolved, and doesn’t print things the same way. One may say that it prints things in a nicer way, but as a result, many of the tests that were suppose to work, actually fails because of these differences in vardump() over time.
So I started working on fixing some of the tests. It’s most of the time very easy to fix, but it takes a long time to fix all these small unit tests. So far, I’ve been able to fix most of what’s in the tests/, Zend/tests (more than 161 tests fixed), and the beginning of ext/*/tests: for the moment: bcmath, bz2, calendar, curl, date, dba, dom, ereg, and a part of exif, which for the moment represent 214 fixed tests, and I’ll try to do more fixes when I have time. I hope to send the patches upstream soon. The final goal is of course to have the build of PHP to fail if unit tests are failing as well. For the moment, unit tests do run at build time, but the build don’t care of the results, which I think is stupid (it’s wasting CPU cycles for no reasons, IMO).
If you maintain some PEAR packages, I would welcome you to first join the PKG-PEAR team on Alioth, and team maintain your packages, switch over to pkg-php-tools and dh 8 auto-sequencer, and to follow the PKG-PHP-PEAR packaging guide lines so that we have consistency in the archive. And of course, run unit testings, by doing a build-depends on phpunit (>= 3.6). Note that unit testings in PEAR packages are tracked on the Debian wiki. This post is also a call for help, because I feel quite alone doing this work of packaging PEAR packages, which many PHP applications depend on (think about roundcube, horde, extplorer, and many more). Other teams are doing very well, like the Perl team, and there’s no reason why Debian wouldn’t maintain PHP libraries as well as the ones for Perl.