Mike Pavlak, Zend Solution Consultant, will be on hand for a PHP distribution shootout.  Expect a lively discussion that explores the features, pros and cons of standard PHP distributions vs. roll-your-own implementations.  Zend Server and other distributions will be examined to see why companies and individuals would opt for one model over the other.  Bring your favorite distribution and join the discussion.  It should be a lively debate!

Testing Zend Framework MVC applications is often seen as a “black art” – but it doesn’t need to be. In this webinar, we’ll look at what to test, how to test, some common testing patterns, and what things you might have difficulty with. We will cover some PHPUnit basics at the start of the session to bring developers new to testing up-to-speed.

Presenter – Matthew O’Phinney

Testing controllers has traditionally been a hassle due to the requirements of setting up the bootstrap, the front controller and initiating the dispatch cycle. In June, Matthew addressed this with the release of Zend_Test_PHPUnit_ControllerTestCase way back in 2008.

Later, Matthew helpfully wrote an article on how to use it and I have used that as a starting point for the information here. (Thanks Matthew!)

The project I’m using is TodoIt, which is a simple ZF demo application, which needs unit tests.

Setting up PHPUnit

All your unit tests will live in the /tests folder. The ZF cli tool will create a phpunit.xml file for you, but you’ll discover that it’s empty! This is what it should look like:

<phpunit colors="true" bootstrap="./TestHelper.php">
    <testsuite name="TodoIt Test Suite">
        <directory>./</directory>
    </testsuite>

    <filter>
        <whitelist>
            <directory suffix=".php">../library/</directory>
            <directory suffix=".php">../application/</directory>
            <exclude>
                <directory suffix=".phtml">../application/</directory>
            </exclude>
        </whitelist>
    </filter>

    <logging>
        <log highlowerbound="80" lowupperbound="50" highlight="true" yui="true" charset="UTF-8" target="./log/report" type="coverage-html"></log>
    </logging>
 
</phpunit>

This file is used to configure phpunit itself and saves having to use command line options. As it’s XML, it’s fairly easy to read. The testsuites element is used to specify the testsuite we’re going to test. In principle you can have many test suites; in this case, one is enough! The filter section is used to specify which files to use for code coverage reporting and the logging section is used to configure the reports.

We also specify TestHelper.php as the bootstrap. This mean that it is called for us and contains the necessary PHP setup we need to do in order to load and use Zend Framework. In effect TestHelper.php acts like public/index.php does for your web application. TestHelper.php looks like this:

<?php
// Based on http://weierophinney.net/matthew/archives/190-Setting-up-your-Zend_Test-test-suites.html

// PHP settings
error_reporting(E_ALL | E_STRICT);
date_default_timezone_set('Europe/London');

define('APPLICATION_ENV', 'unittesting');
define('APPLICATION_PATH', realpath(dirname(__FILE__) . '/../application'));

// Directories for include path
$root = realpath(dirname(__FILE__) . '/../');
$library = $root . '/library';
$models = $root . '/application/models';

$path = array(
    $library,
    $models,
    get_include_path()
);
set_include_path(implode(PATH_SEPARATOR, $path));

require_once 'Zend/Loader/Autoloader.php';
Zend_Loader_Autoloader::getInstance();

// Unset global variables
unset($root, $library, $models, $path);

As with public/index.php, we set APPLICATION_ENV and APPLICATION_PATH, update the include_path and then set up the autoloader. Now we’re all ready to write some tests!

A controller test class

I place my controller test classes in tests/application/controllers to make them easy to find. (Model tests go in tests/application/models!). The TodoIt application has a login form in AuthController::indexAction() which is accessed via the /auth URL. We’ll start by testing this form is displayed.

The controller’s test class is called AuthControllerTest and lives in tests/application/controllers/AuthControllerTest.php:

<?php

// Call AuthControllerTest::main() if this source file is executed directly.
if (!defined("PHPUnit_MAIN_METHOD")) {
    define("PHPUnit_MAIN_METHOD", "AuthControllerTest::main");
}

require_once 'PHPUnit/Framework/TestCase.php';

/**
 * @group Controllers
 */
class AuthControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public static function main()
    {
        $suite  = new PHPUnit_Framework_TestSuite(get_class($this));
        $result = PHPUnit_TextUI_TestRunner::run($suite);
    }
    
    public function setUp()
    {
        $application = new Zend_Application(
            APPLICATION_ENV,
            APPLICATION_PATH . '/configs/application.ini'
        );

        $this->bootstrap = $application;
        return parent::setUp();
    }

    public function tearDown()
    {
        /* Tear Down Routine */
    }

    public function testLoginDisplaysAForm()
    {
        $this->dispatch('/auth/index');
        $this->assertQueryContentContains('h1', 'Login');
        $this->assertQuery('form#login'); // id of form
    }
}

There’s three things going on in here, so let’s look at each in turn.

Firstly we set up the file to allow PHPUnit to run this file on it’s own using the command line:

phpunit tests\application\controllers\AuthControllerTest.php

This is done by setting the PHPUnit_MAIN_METHOD constant to the static method AuthControllerTest::main(). The phpunit cli tool will then run this method which will in turn run this file as a test suite.

The methods setUp() and tearDown() are called before and after every test method and are used to ensure that we have a clean slate for each one. As we extended from Zend_Test_PHPUnit_ControllerTestCase rather than from PHPUnit_Framework_TestCase, we are able to leverage functionality specifically designed to make testing controllers easier. We use this in setUp() to set the property bootstrap to an instance of Zend_Application, which is then used in the tests themselves.

Each test is a method that starts with the word test, like this one:

    public function testLoginDisplaysAForm()
    {
        $this->dispatch('/auth/index');
        $this->assertResponseCode(200);
        $this->assertQueryContentContains('h1', 'Login');
        $this->assertQuery('form#login'); // id of form
    }

We start by calling dispatch() to run the correct action and then we use the various assert methods to check that the result is what we expect. The assertResponseCode method checks that we didn’t error as the errorController will set the code to 500 or 404. We can then use the assertQuery methods to check what has been rendered to the response object. These use DOM paths to select a specific element. The call to assertQueryContentContains allows us to check the text within the H1 element is what we expect and the assertQuery just checks that the element is on the page.

That’s it.

This is just the tip of the iceberg and I strongly suggest that you have a read of the documentation to see for yourself how many different assertions you can use to check that your code is performing as expected.

The Zend Server Training Course provides System Administrators or Operators (or individuals who fulfill similar functions) with the knowledge and confidence to successfully utilize Zend Server in their critical role of providing a stable, secure, and robust server environment to both internal and external users.

After completing the course, participates will be prepared to:

    * Maximize the availability and performance of their production environment
    * Rapidly respond to any issues, and shorten the time to resolution
    * Setup and provide their development staff with a Business-grade PHP environment

This course is offered online – with a live instructor – for 10 hours (five 2-hour sessions)

The Zend Quick Start: PHP for OO/Proc Programmers course is designed to quickly build an experienced programmer’s understanding of the PHP language. This course covers many of the same topics as both the PHP I: Foundations and PHP II: Higher Structures classes but at an accelerated rate with special emphasis on the differences between PHP and other commonly used languages.

This course is offered online – with a live instructor – for 18 hours (9 – 2 hour sessions).

The PHP I: Foundations course is designed to provide non-programmers with a solid foundation in the PHP language. This course guides you through the basics of PHP with an experiential approach, filled with numerous examples and hands-on exercises, including substantial practice in coding a functional application. All of the exercises are designed to reinforce key learning.

You will also have the opportunity to use the Zend Studio IDE (Integrated Development Environment) to start your coding adventures the easy and correct way!

concrete5 is an open-source content management system (CMS) built in PHP on top of Zend Framework.

Attend this webinar to see how using Zend Framework enabled concrete5 to solve real-world problems for a large and diverse customer base. Andrew Embler, CTO of concrete5, will talk about how they leveraged Zend Framework’s structure and tools to build an enterprise-class CMS.

Last week, while I was on vacation, the news broke that IDG’s InfoWorld had announced its annual
InfoWorld Bossie Award winners
(“Bossie” stands for “Best of Open Source Software”), and that Zend Framework had won the ” best open source application development software ” award.

Join Zend at Asia’s largest Open Source Conference.  The conference will host a wide variety of PHP sessions including those from Kevin Schroeder, Zend Technology Evangelist:  Building Applications with Zend Framework and Using Zend Server to Run your PHP Applications.