{ "href": "/post/2005/01/19/savant3-and-unit-testing/", "relId": "2005/01/19/savant3-and-unit-testing", "title": "Savant3 and Unit Testing", "author": "pmjones", "markup": "html", "tags": [ { "href": "/tag/php/", "relId": "php", "title": "PHP", "author": null, "created": null, "updated": [], "markup": "markdown" } ], "created": "2005-01-19 19:14:33 UTC", "updated": [ "2005-01-19 19:14:33 UTC" ], "html": "

I'm starting work on Savant3, which will be PHP5 E_STRICT compliant, and the work is going nicely; I should have an alpha release at the end of the week. This time around, I'm doing real unit tests, and I can now say I am a fan of unit testing. With Savant2, I used \"eyeball\" testing (described here) but that was no fun at all.

\n

The real problem with unit tests is not writing them; in fact, it's kind of fun trying to figure out how to break the library and then come up with a test for it. No, the trouble was figuring out how to *do* unit tests in the first place. After cursory reviews of SimpleTest and PHPUnit, I was less than enthusiastic; they are their own applications in many ways, and not that intuitive for the new unit-testing initiate (me).

\n

However, the .phpt methodology easy to approach and apply ... once I found it and figured out how to do it. There is some official documentation here (although it does not seem to be widely advertised), and a tutorial-like overview from Aaron Wormus here at the very end of the article.

\n

Between those two pages, and a day spent experimenting, I am now putting together a unit test suite for Savant3. Let me tell you, it is *much* easier to call pear run-tests *.phpt than it is to load the individual Savant2 test pages in a browser and eyeball them for errors. I'm not sure how difficult it would be to apply unit testing to a complex application, but in a library with limited behaviors, it's relatively easy to do and has a high reward-to-effort ratio.

\n

Update (19 Jan, 23:15 CST): You can find the Savant3 CVS repository here.

\n" }