Savant3 and Unit Testing

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.

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

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.

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.

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

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

10 thoughts on “Savant3 and Unit Testing

  1. It’s probably too late now, but you might want to also consider Apache-Test. It sounds very similar to the .phpt testing approach – in fact, I think the Perl test harness is where the idea of .phpt arose.

    The largest improvement I can think of is that you actually test your applications in the environment in which they will run, not some command line utility. This lets you more easily write tests that are web-centric – form processing, etc. Of course, this goodness is only available for Apache.

    You can read a bit more about it here:

  2. You know what, Paul? You’re right. It took me a day of milling around LastCraft to figure out how to use it. At that, I’m still discovering parts of it as I’ve just started using the WebTest portion of it. I’m on the dev team at SimpleTest, and seeing how I’m in a holding pattern on it until we start up with v1.1, I may just put together a quick explanation of how it works.

    One major benefit I see to the SimpleTest/xUnit route is that you can comment on what each part of the test is doing. You can still do that to some extent with the phpt route, but I guess I’m just partial.

    The real power in a unit testing package is Mock objects. You could use those to create a mock database object and control what that object returns back to any given method thus allowing you to create a fully controlled test environment. Of course, that’s more than what Savant would need, but the option is there.

    I’ll keep you posted on the SimpleTest article.

  3. Unbeknownst to many, there’s also a unit test class in pear-core. I didn’t know about this until I had an email exchange with Greg Beaver about it. He advocated using the phpt files with the unit test class.

    I can’t find the conversation I had with Greg, but here‘s the class file in cvs. It’s rather undocumented, but has been quite useful to me, because it uses Text_Diff to output a messages when the tests fail.

  4. I personally hate the .phpt tests, but love SimpleTest and PHPUnit2. I’m wondering if you’ve considered PHPUnit2, in particular, since you are using PHP5. It works particularly well with code that throws Exceptions; for my projects that’s extremely valuable. Sebastian has done great things in PHPUnit2, and I think it’s just about as easy to use from the CLI as the .phpt tests — and as far as I’ve seen a *much* *much* *much* cleaner (particulary for OO code) and easier to integrate with other tools (e.g. Phing has PHPUnit2 support).

    P.S. Do you know that you’re comment input box is wider than your DIV in Firefox? Weird “scrolling” effect when entering a comment, unless I use CTRL– to shrink font.

  5. Hi, Hans — fixed the input box, thanks.

    Let me sum up my reason for not using PHPUnit2 by quoting its PEAR information page: “No end-user documentation is available for this package.” Life is hard enough without having to learn a new package only from the source code. 🙁

  6. Yes, there’s not a lot of documentation for PHPUnit2, but there is some:

    Also, it’s essentially an exact port of JUnit, so almost every JUnit doc aplies directly to PHPUnit2 (and for the most part to SimpleTest also).

    Unit tests are good, of course, regardless of the technology. I just find the PHPUnit2 solution to be particularly elegant — if somewhat under-documented.

  7. I came to the same conclusion, phpt’s once you’ve figured out how to run the test suite, the tests are alot simpler, quicker to write, and produce pretty much the same result as a full blown phpunit.

    BTW: any public svn/cvs repo for Savant3.. ?

  8. Hmm, using a unit Test-Tool isnt really a problem. Read a tutorial and get into training …
    The point might be that testing is a own discipline .. like you get a tennis racket and try to figure out how it works.
    If you know how to play tennis its just easy to get to any court with any rack and play …
    Anyway .. i am a simpletestist 😉 and like that one very much … its just a good tool for a lazy guy like me ..

    anyway … testing with PHPUnit or Simpletest is good for sleep at night and getting at home in time on deadline days ….
    to less people got that until now ….

Leave a Reply

Your email address will not be published. Required fields are marked *