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