I decided to get serious with unit/integration testing, and have found the practice to be well worth it. I started off with the base understanding that the purpose of unit testing was to test code, but wasn’t sure in what way. I dove in, and here I am now documenting my findings.

I have broken up this subject into two parts; basic and advanced use. Basic is theory and simple unit testing information, while advanced covers globalized test configuration and setup, and database integration.

In the development life cycle, unit testing can exist before or after coding, depending on which development approach is being taken. Some are in the practice of creating unit tests before they begin generating code for their application, while other models have unit testing as a post-coding task. While the variations of development models is interesting, it falls outside the scope of this post.

Unit tests are commonly written to ensure a unit of code (ex. class or function)  work as intended. There is also integration testing, which is typically done after unit testing, and is meant for grouped units of code or “black box” integration, such as a database where the interface is being tested and not the functions behind that interface.

In addition to ensuring code is working as desired, tests act as documentation, which contributes to the often neglected documentation step of the development life cycle.

Now that we have an understanding as to what these tests are and what they’re meant for, let’s create a test.

Prerequisites

My environment was setup with:

• PHP
• PEAR
• PHPUnit

Creating a Test Class

Folder Structure & Naming Conventions

Tests typically reside in a separate folder at the root of the project, this way the files are isolated from the production code base, and it is easy to exclude test files.

File and class names follow a *Test.php naming convention.

For function names, they should either follow test*, or use the @test annotation.

Examples:

public function testNullTypeInConstruct() {
    // Code here
}


/**
* @test
*/
public function functionToTestSomethingElse() {
    // Code here
}

Writing out a descriptive name for each test method makes it easier to keep track of what does what from a glance, especially when using features like testdox, which changes method names into a human readable format.

Skeleton Generator

A “skeleton” test class with can be created automatically based on an existing class by using the skeleton generator. This does not generate all test functions in one shot, but does get you started off on the right foot.

Test Setup and Tear Down

Maintaining a sanitized testing environment is key. PHPUnit includes methods for setting up and removing remnants of  previous tests. The two main methods are named setUp and tearDown.  The names are self-explanatory, setUp runs prior to each test and is intended for initializing variables for each test, while tearDown is for clean up.

Non-global variables are wiped out after each test, so PHP clean up requires little to no effort, as variables are automatically moved into garbage collection and dumped at the end of the script. Only in resource intensive tests should there be any need to consider extra steps in clean up.

Annotation

Annotations can be made to alter the behavior of a test function, such as indicating an exception is expected to be raised in a test. For example, ExpectedExceptions can be noted by annotation or a set function.

Annotations live inside PHP comments. There was an oddity I came across, which is worth noting. I had to use a double asterisk at the beginning of the comment. So I make sure to use /** instead of /* to begin my comments.

Asserting

Here we have the test itself, everything else was the setup. An assertion is a declaration that something should be as defined, or in the case of expected exceptions, it should not be. There are a wide variety of predefined insertions that can be used on booleans, strings, objects and arrays. A full list can be found in the PHPUnit documentation.

Putting It All Together

class MyClass {
    public $foo = 42;
}

require_once dirname(__FILE__) . '/../../classes/MyClass.php';

class MyClassTest extends PHPUnit_Framework_TestCase {
    protected $object;

    protected function setUp() {
        $this->object = new MyClass;
    }

    protected function tearDown() {

    }

    function testFoo() {
        $this->assertEquals($this->object->foo, 42);
    }

}

What’s next?

Here you have information to build a very simple unit tests. Methods can be tested to assure they behave correctly and return expected data regardless of input. In the next post, we take a look at advanced features and working with integration testing.