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 P''''''hbUnit.
----

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

--GeorgePaci

----

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.

--SebastianBergmann

----

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.

----

CategoryPhp  CategoryTesting