Finally! We can start testing our Controllers! I will assume that your application has the same directory structure as the Zend Framework Quick Start tutorial. Here’s an overview of what our directory structure will look like:

/myApp/application/controllers
/myApp/tests/application/controllers

Our tests directory will mirror our application. We might also include a ‘library’ directory in the tests directory so we can test our custom library components. For now, we’ll just keep it simple and test our controllers.

Now, we’ll create a file that will take care of auto loading. Create a new file called ‘loader.php’ in you tests directory. All of our tests will require this file.

1
2
3
4
5
6
7
8
9
10
11

<?php
 
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application/'));
 
set_include_path( APPLICATION_PATH . '/../library' . PATH_SEPARATOR .
APPLICATION_PATH . '/models' . PATH_SEPARATOR .
APPLICATION_PATH . '/forms' . PATH_SEPARATOR .
get_include_path() );
 
require_once "Zend/Loader.php";
Zend_Loader::registerAutoload();

Now let’s create a simple controller test. We’ll call this ‘IndexControllerTest.php’ and put it in our tests/application/controllers directory. We just need to set the location of our bootstrap file. When Zend_Test_PHPUnit_ControllerTestCase constructs, it will look for the bootstrap file that we set here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
 
require_once '../loader.php';
 
class IndexControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = '../../application/bootstrap.php';
 
    public function testIndexAction()
    {
    $this->dispatch('/index');
    $this->assertController('index');
    $this->assertAction('index');
    $this->assertResponseCode(200);
    }
 
}

That’s it! All we have to do is run this file with our PHPUnit command line interface (that we used in the last tutorial).

Now that we’ve installed PEAR and PHPUnit, we can verify that PHPUnit is working correctly by writing our first test.

Since we installed PHPUnit through PEAR, and we have properly configured our include_path variable in our php.ini file, we can create our test files anywhere and PHP will know where to look to find PHPUnit. So I will create a new file in my /Users/andrew/Sites directory and call it FoobarTest.php with the following contents:

<?php

class FoobarTest extends PHPUnit_Framework_TestCase {

public function testFoobar() {
$this->fail();
}

}

By writing our function name to start with “test”, PHPUnit will know to run this function as a test. Typically you will want to name your test functions with names similar to the functions that you are testing, preceded by “test”.

Now let’s run our test!

cd /Users/andrew/Sites
phpunit FoobarTest.php

You should see something like the following:

PHPUnit 3.3.15 by Sebastian Bergmann.

F

Time: 0 seconds

There was 1 failure:

1) testFoobar(FoobarTest)
/Users/andrew/Sites/FoobarTest.php:6

FAILURES!
Tests: 1, Assertions: 0, Failures: 1.

Yay! It works! “But wait,” you say, “it says failures. Why is this a good thing?” Test-driven development is all about writing tests first. Remember this saying: Red, Green, Refactor. Start by writing the test, which will fail, of course, because you haven’t written any code yet! Then write the code until your test passes. Then STOP. There’s no need to keep writing. The code is finished. You know it works because you have the test to prove it. Tests are written to fail. Code is written to fix the tests.

However, this is a poor example of a test, so let’s write a real one.

Let’s start by thinking about what we want to build. How about we build a class called Foobar (to make things easy since we already have a FoobarTest) that has a function called getMessage(). However, getMessage() doesn’t return a string like we might expect, it returns an array. A test for that might look like the following. Also note that our function name is a little more verbose. Tests can serve as a sort of documentation. Think of underscores as commas and name your functions to explain what happens in the test.

<?php

class FoobarTest extends PHPUnit_Framework_TestCase {

public function testGetMessage_ReturnsAnArray() {
$foobar = new Foobar();
$message = $foobar->getMessage();
$this->assertTrue(is_array($message));
}

}

Now if we run our test again, we should see the following:

PHPUnit 3.3.15 by Sebastian Bergmann.

PHP Fatal error:  Class 'Foobar' not found in /Users/andrew/Sites/FoobarTest.php on line 6

Fatal error: Class 'Foobar' not found in /Users/andrew/Sites/FoobarTest.php on line 6

Now we have an error that says PHPUnit can’t find our Foobar class. Well that’s because we haven’t created it yet! So create a new file in the same directory as our test, name it Foobar.php, and give it the following contents:

<?php

class Foobar {

}

Next, let’s update our test so it knows where to find our new class:

<?php

require_once('Foobar.php');

class FoobarTest extends PHPUnit_Framework_TestCase {

//...

That’s all we need to do. Remember, all we are trying to do is get the test to pass. Right now the test tells us that we need to create a Foobar class so that’s what we’ve done. Let’s run our test again and see what it says.

HPUnit 3.3.15 by Sebastian Bergmann.

PHP Fatal error:  Call to undefined method Foobar::getMessage() in /Users/andrew/Sites/FoobarTest.php on line 9

Fatal error: Call to undefined method Foobar::getMessage() in /Users/andrew/Sites/FoobarTest.php on line 9

Hooray! We no longer have the same message as before. Now we need to create our getMessage() function in our Foobar class.

<?php

class Foobar {

public function getMessage() {

}

}

Run our test again and we should see another change:

PHPUnit 3.3.15 by Sebastian Bergmann.

F

Time: 0 seconds

There was 1 failure:

1) testGetMessage_ReturnsAnArray(FoobarTest)
Failed asserting that <boolean:false> is true.
/Users/andrew/Sites/FoobarTest.php:10

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

getMessage() doesn’t return anything, so let’s change that:

<?php

class Foobar {

public function getMessage() {
return array();
}

}

That should be enough for us to get our test to pass. Let’s see if it works.

PHPUnit 3.3.15 by Sebastian Bergmann.

.

Time: 0 seconds

OK (1 test, 1 assertion)

It works! We’re done. I think you get the picture. Let’s move on to some actual controller tests.

Question: How do I get started using Zend_Test? What is the process necessary to start using Zend_Test for testing my Zend Framework application?

Answer: Zend_Test extends PHPUnit. Therefore, we need to start by installing PHPUnit. The easiest way to install PHPUnit is by installing PEAR. Therefore…you get the idea. We need PEAR. I’ll walk you through the process I took to install PEAR on Mac OS X 10.5 (Leopard).

Open up your trusty Terminal application by going to /Applications/Utilities.

First, we’ll switch over to a user that has enough permission to do anything, our super user:

sudo su -

Next, we’ll change directories to /usr/local by typing:

cd /usr/local

Then, we’ll download and run the pear installer:

curl http://pear.php.net/go-pear | php

Press enter to begin the installation process. Press enter again to use no HTTP proxy. You should then see a screen with seven installation locations. The first one should say /usr/local. If this is not the case, press 1 and enter. Type /usr/local and press enter again. Now we should all be on the same page.

Press enter to continue with the installation. When asked, you can accept the additional PEAR packages by typing Y and pressing enter.

The installer will run through the installation, downloading and installing the necessary packages. Eventually the installation will finish. You may receive a warning that your php.ini file does not contain the PEAR PHP directory we specified (/usr/local/PEAR). This is okay. We will be editing this file in the next step. So simply type n and press enter. Press enter againto finish the installation. PEAR should now be installed and ready to use. Let’s see if it works by typing:

pear version

We should see a few lines including the version of PEAR we just installed, PHP version, etc. But wait, we’re not done yet! We still need to edit our php.ini file. If you don’t have a php.ini, you’ll need to create one by copying the php.ini.default:

cp /etc/php.ini.default /etc/php.ini

Now were ready to edit our php.ini file. Open the file with Pico (or any other text editor):

pico /etc/php.ini

Scroll down about 1/3 and find the line that says:

;include_path = “.:/php/includes”

The semicolon at the beginning of the line means it’s commented out. Replace this line with the following:

include_path = “.:/usr/local/PEAR”

Press Control + O, then enter, to save your changes. Then, Control + X to exit Pico. Restart your Apache server and you should be good to go!

apachectl restart