There is an implementation of PhpUnit available as part of the PhpPear? native libraries found at http://pear.php.net/package-info.php?pacid=38
The rest of this page concerns a separate implementation.
PhpUnit is a rudimentary implementation of the TestingFramework in PHP3 [it has since been updated to work with 3 and 4]. Please see http://www.ontosys.com/phiki/PhpUnit for more information. --FredYankowsk?
I've been extending PhpUnit over the last several weeks with some things I find useful (e.g. compare a URL to a file, show a color-coded diff, and let you approve the differences by clicking a link).
If anyone's interested, I can probably clean the code up (maybe I should treat test code like production code...) and submit it to the CVS archive. --GeorgePaci
I think it's a bad idea to put functionality into PhpUnit that's not directly related to managing and reporting on tests (like making color-coded diffs). This contradicts do-one-thing-and-do-it-well and DoTheSimplestThingThatCouldPossiblyWork. The particular case of having to "approve differences" also contradicts CheckOutputAutomatically.
I've also done a lot of refactoring on PhpUnit, mainly to make it easier to extend. The main user-visible features are a test profiler, and email- and ascii- test reports. The responsibilities between classes are a bit more cleanly divided, but it breaks the mold of JUnit. I've sent my changes to FredYankowski for him to include in his version as he sees fit; I'll send them to you too if you ask. --AdrianKubala
Eventually I'm going to stop reading this as PhbUnit.
(Wish I'd checked on this page sometime in the past six months; still, better late than never:)
I added functionality to PhpUnit because I needed it. I frequently found myself making a small change, breaking a few test cases a little bit, and having to manually update them. So I added a "BLESS" feature to one of the assert methods: PhpUnit shows me the failed test's actual and expected output (as usual), and if the changes to it are OK, I can just click the "BLESS" link, saving myself at least a minute each time. (Note that I only have to approve tests when they FAIL, not every time; I wasn't very clear about this above.)
After a while, I got tired of using Emacs to ediff the more complicated failed tests, and added some simple color-coding that usually makes it obvious what changed. Again, I did this because it made my life easier.
Finally, I put these things in a subclass of TestCase, so whatever mods you made to the existing PhpUnit classes will probably be very easy for me to integrate. We're not getting in each other's way here.
By the way, have you figured out some intelligent way to simulate exceptions in PHP? Or to get a test to quit once one of its assertions fails? (I haven't thought much about the latter.)
There seems to be several PHP unit testers all called PHPUnit. Is this one still active?
--MarcusBaker (I've since written SimpleTest)
My PHPUnit (see http://www.phpunit.de/) is the most complete xUnit-Port for PHP and very much alive. It is a complete port of JUnit 3.8.1, includes the functionality of junitour and allows for Code Coverage analysis.
You use Unit testing to help you build and run tests. A PHP Test Coverage tool is a very nice complement, as it tells you what your tests have tested. See http://www.semanticdesigns.com/Products/TestCoverage/PHPTestCoverage.html.