Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History
If you have written testing standards previously, please read the guidelines below, and help author testing standards for the Zend Framework.

Why use unit tests?

Components will not be included in Zend Framework releases without a reasonable collection of working unit tests. This includes incubator components.

Test Standard Goals

We are moving towards continuous integration and are looking at having a build/test server (build docs, api docs and run tests) responding on check-in similar to CruiseControl.

  • Sane defaults
    • default database names, usernames, passwords, etc. should not conflict with existing ones
    • desired [database] account restrictions and access should be included
    • include example database creation scripts for each of the tested database engines
    • reports produced in less than 15 minutes on typical systems
  • All tests work out of the box, with minimal configuration
  • Test startups and teardowns should be "smart" with persistent data, such that restarting the testing process works, regardless of possibly aborted previous tests. Various components may help, including Zend_Http_Server.
  • Zend_Environment runs first (to determine if the environment meets minimum ZF requirements)

Zend Framework Testing Standards Best Practices

  • Zend Framework unit tests are written for PHPUnit.
    • New install:
    • Upgrading:
    • Upgrading from PEAR/PHPUnit2:

When you're having trouble installing the newest PHPUnit Version 3 and after upgrading your PEAR say that the newest PHPUnit Version 2.3.6 is already installed the following instuctions will help you

Look per browser at and see what's the latest release...
Today for example the latest release version is
Now do the following

and you will have the latest PHPUnit Version installed.

Check your version by changing your working directory to PHP and run phpunit on command line.
The actual version and help should show up.

Code coverage

The Xdebug package enables code-coverage reports in HTML: $ pecl install

If the beta version is relatively "stable", then try:

And edit your php.ini file:

And use the "--report=<dir>" to generate HTML code coverage reports in <dir>.

Generating Tests

To test the framework the following prerequisits have to be done:

Change the files

For example if you want the report to be produced in the directory C:\temp\reports

Before change

After change


Commandline Failure Report

To produce the report go to commandline, change the active directory to
eighter /tests or /incubator/tests and enter

This can take a while. After the complete test is run, you will have a summary of completed, failed and not run tests.

Code Coverage Report

To produce a web-based code coverage report go to commandline, change the active directory
to either /tests or /incubator/tests and enter

phpunit --reports C:\temp\reports AllTests.php

After the tests have run, you will find the html-based report in the directory
C:\temp\reports... or the directory you entered here.

Writing tests

Help on writing tests is very welcome.
We will have 2 goals to cover.

100% Code Coverage

Target is to cover 100% of our code, to find codelines which are not used so they can be erased.

Several Test cases

Target is to test the code for different inputs, correct behavior and output.
Think of an input parsing class for numbers.
We would have to test

  • no input
  • whitespace input
  • positive numbers
  • negative numbers
  • decimal numbers
  • float numbers
  • Strings which include numbers
  • Exception thrown
    and so on...

Of course the test for negative numbers will cover 90% of all codeline. But without the other tests
we will not know if our classes behavior is as expected.

If someone writes new tests to cover goal one or two to components for which he is not a contributor,
please write a new issue.

Using the Test Helper

In the tests directories of the core and incubator are files named TestHelper.php. This script is provided to aid with general unit testing setup, such as using the proper error_reporting level, setting up the include_path, etc.

Whether you are writing a test case class that extends PHPUnit_Framework_TestCase or you are writing a full test suite, you can use a simple directive to provide this automatic setup for you. An example follows:

You may need to call the dirname() function additional times, depending on how deep in the directory tree your file will be located.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.