Controlling time

There are often a lot of obvious variables that could affect a unit test case, especially in the web development environment in which PHP usually operates. These include database set up, file permissions, network resources and configuration amongst others. The failure or misinstall of one of these components will break the test suite. Do we add tests to confirm these components are installed? This is a good idea, but if you place them into code module tests you will start to clutter you test code with detail that is irrelavent to the immediate task. They should be placed in their own test group.

Another problem, though, is that our development machines must have every system component installed to be able to run the test suite. Your tests run slower too.

When faced with this while coding we will often create wrapper versions of classes that deal with these resources. Ugly details of these resources are then coded once only. I like to call these classes "boundary classes" as they exist at the edges of the application, the interface of your application with the rest of the system. These boundary classes are best simulated during testing by simulated versions. These run faster as well and are often called "Server Stubs" or in more generic form "Mock Objects". It is a great time saver to wrap and stub out every such resource.

One often neglected factor is time. For example, to test a session time-out coders will often temporarily set the session time limit to a small value, say two seconds, and then do a sleep(3) and assert that the session is now invalid. That adds three seconds to your test suite and is usually a lot of extra code making your session classes that maleable. Far simpler is to have a way to suddenly advance the clock. To control time.

A clock class

Again we will design our clock wrapper by writing tests. Firstly we add a clock test case to our tests/all_tests.php test suite...

<?php
if (! defined('SIMPLE_TEST')) {
    define('SIMPLE_TEST', 'simpletest/');
}
require_once(SIMPLE_TEST . 'autorun.php');
require_once('log_test.php');
require_once('clock_test.php');

$test = &new TestSuite('All tests');
$test->addTestCase(new TestOfLogging());
$test->addTestCase(new TestOfClock());
$test->run(new HtmlReporter());
?>

<?php
require_once('../classes/clock.php');

class TestOfClock extends UnitTestCase {
    function TestOfClock() {
        $this->UnitTestCase('Clock class test');
    }
    function testClockTellsTime() {
        $clock = new Clock();
        $this->assertEqual($clock->now(), time(), 'Now is the right time');
    }
    function testClockAdvance() {
    }
}
?>

<?php
class Clock {
    
    function Clock() {
    }
    
    function now() {
    }
}
?>

class Clock {
    
    function Clock() {
    }
    
    function now() {
        return time();
    }
}

Group test tidy up

Our all_tests.php file has some repetition we could do without. We have to manually add our test cases from each included file. It is possible to remove it, but use of the following requires care. The TestSuite class has a convenience method called addFile() that takes a PHP file as a parameter. This mechanism makes a note of all the classes, requires in the file and then has a look at any newly created classes. If they are descendents of TestCase they are added as a new group test.

In addition the autorun library will run all the collected test cases automagically after loading them.

Here is our refactored test suite using this method...

<?php
if (! defined('SIMPLE_TEST')) {
    define('SIMPLE_TEST', 'simpletest/');
}
require_once(SIMPLE_TEST . 'autorun.php');

class AllTests extends TestSuite {
    function AllTests() {
        $this->TestSuite('All tests');
        $this->addFile('log_test.php');
        $this->addFile('clock_test.php');
    }
}
?>

1. If the test file has already been included, no new classes will be added to this group
2. If the test file has other classes that are related to TestCase then these will be added to the group test as well.