Improved Test Assets for Zend_Tool Generated Projects in ZF 1.11.4

    Please note: This article is being reposted and aggregated due to technical difficulties with the original post – the old link is no longer valid.

As of the 1.11.4 release of Zend Framework, the generated testing stubs just got a little saner. At the time of Zend_Tool’s initial release, the standard application structure you are familiar with today was just being released as well with Zend_Application. In addition, the testing controllers from this newly standardized application layer, were too, in their infancy. In short, we had known that the stubs being produced in the tests/ directory were incomplete, but we were waiting to see if there were improvements to Zend_Test on the horizon that might improve the way controllers were tested- and to see if these new methods would become best practices.

Recently, while Sebastian Bergmann was working on his pet project php-project-wizard, he noticed a few inconsistencies with the stubs that Zend_Tool was generating and decided to send us some recommendations on how to best leverage PHPUnit 3.4+ to test our application’s assets. In addition to his observations, we added a few more changes to the stubs that might make your workflow moving forward a little easier.

Let’s have a look.

As always, it starts by generating a project:

One of the first things you’ll notice is that the tests/ directory has changed a bit. There is a single bootstrap.php file that is now officially referenced from inside the phpunit.xml file that now has some working values that PHPUnit likes.

NOTE: It’s worth noting here that much of the generation of the following application assets that relate to testing require that PHPUnit was installed correctly and is inside your include_path.

Here is the phpunit.xml and the bootstrap.php contents:

In addition to generating working PHPUnit assets, we also created the test controller file for the initial IndexController. This class now has a matching indexActionTest that will test the start page for your new Zend Framework application. Out the box, if you change to the tests/ directory and attempt to run PHPUnit, the default behavior will be to run all the tests, which includes this IndexControllerTest.

As you can see, a single test was run for our initial index controller / index action combination. This initial indexActionTest has some minimal testing behavior built in to help you get started fully testing your actions (about 4 assertions testing the request object and content of the output). This initial IndexControllerTest will naturally start to fail as your IndexController’s output changes. When this happens, you can refer to this initial IndexControllerTest for reference when it comes to keeping the tests in your application’s test directory from failing.

Before we get into the actual contents of the action tests, let’s generate a new controller and new action so we can have a full look at what is being generated.

If we have a look at the file based assets that were generated, you’ll see the project structure now looks like this:

Each new controller and action now has a corresponding controller test and action test.

In these test controllers, you’ll see that we now have some minimal bootstrapping of the controller request lifecycle and then a single content match test. Ideally, you do a little more testing inside these stock action tests, but this should help get you started.

Lastly.. it works for modules too!

The only change here is that our actions can now

Finally, without altering any of the actual code in the project, we can run phpunit in the tests directory and see some working output: