One of my ongoing projects the past few months has been to create an infrastructure for functional testing of ZF projects using PHPUnit. This past weekend, I made the final commits that make this functionality feature complete.

This new functionality allows you to create stub test case classes, use a Zend_Dom_Query object with CSS selectors/XPath for queries and makes available a special PHPUnit test case that handles the interface between some of the custom functionality (boostrapping, dispatching requests, etc) and PHPUnit.

He includes a sample test case that has assertions for calls to a controller with an action, that a page contains a login form and that a page creates a session and redirects to a profile page.

You can get this functionality from the incubator on the subversion repository for the project.

It is hard to test code that uses singletons. The same is true for code that uses global variables. Typically, the code you want to test is coupled strongly with a global variable and you cannot control its creation. An additional problem is the fact that one test's change to a global variable might break another test.

You can disable the backup option if you'd like by setting the $backupGlobals option in your test to false. This lets PHPUnit know that you want to leave the globals (and superglobals) alone during the run.

While being an easy read, this is a well written, serious book and is aimed squarely at enterprise-level developers and software engineers who make their living through the development and architecture of solutions developed in PHP.

He breaks down the book into the three sections its title mentions - working with objects, design patterns and a healthy dose of PEAR, phpDocumentor, PHPUnit, CVS and phing.

I've recently been working on a project trying to take an existing customized wordpress site and create automated integration tests around parts of it. I'm using phpUnderControl, phpUnit, Selenium RC, Firefox, Xvfb (virtual frame buffer) and...well, I think that's it.

He mentions the two issues he came across, both with the WordPress software (the "siteurl" setting and the pathing for the templates). He recommends that application code be portable to avoid problems like these. Applications that can be dropped in anywhere and "just work" can help not only make life easier for the installer but also for the tester.

Recently, I wrote some for a project and realized that I wasn't aware of how to generate code coverage reports. Many thanks to the very helpful patrons in the #pear channel on EFNet for helping me to get this working.

He show his setup process (on Kubuntu) - grabbing the PEAR package, installing it and how to get a runner script to integrate the PHPT testing into PHPUnit.

For now over three years we are working with unit tests. I'd like to share some of those experiences. As we have two frameworks in place for our website, I can compare two different strategies for unit tests.

He talks about their choice of SimpleTest, their test monitoring, CruiseControl and their "if it doesn't pass, you can't release it" mentality to keep their site as bug free as possible.

Instead of instantiating PHPUnit from phing, I use the command line interface to call PHPUnit. This decouples phing and PHPUnit, which should cause less problems with version updates in the future. To configure PHPUnit, phing creates a temporary XML configuration file which is deleted after PHPUnit has finished.

The source is included in the post - it manually builds the XML file needed for phing to do its job.

Given a directory, the test runner will recursively scan the directory for *Test.php files, build a test suite out of the *Test classes, and run it.

PHPUnit is framework that makes writing tests for your code easy and also includes functionality to run the tests and analyze their results.

Check out the screenshots here and here.

PHPunit is a member of the xUnit family of testing frameworks and provides both a framework that makes the writing of tests easy as well as the functionality to easily run the tests and analyse their results.

His example builds the class off of a set of test for a "BowlingGame" that ends up with roll() and score() methods based off of the naming conventions used in the test:

Following the convention that the tests for a class BowlingGame (see below) are written in a class named BowlingGameTest (see above), the test case class' source is searched for variables that reference objects of the BowlingGame class and analyzing what methods are called on these objects.