A command line runner script for AperiTestCase.
Note that, although Aperiplus unit testing code builds on SimpleTest, it's not compatible with standard SimpleTest test cases. The runner code assumes a few extra bits and pieces which don't exist in UnitTestCase and so you cannot mix the two together in any way. For example, you can't have UnitTestCase-derived tests in the same file as an AperiTestCase-derived test case. You can't even have them in different files in the same directory.
Although the runner script can run tests anywhere in the filesystem, different projects will almost certainly have different configuration needs and possibly clashing settings. In practice you'll need a unique runner file per project, each loading the relevant config stuff.
Runner scripts are pretty simple:
<?php
require_once('aperiplus/lib/simpletest-extensions/runner.php');
# configure any settings you might need for the codebase
# constants, registry values, etc
# ...
exit(call_user_func_array(
array(new Test, 'getStatus'),
array()));
?>
A real life example as used by aperiplus can be viewed here.
For the rest of this page, I'll assume the new runner file has been saved as "test.php".
help:
$ php test.php -h
The runner script will run every test case it can find in a given path. To run all tests in a dir (recursive):
$ php test.php foo/
Note that the script only looks for test cases in files with a ".php" extension. Others will be ignored.
Run all tests in a file:
$ php test.php foo/file.php
Run single test cases:
$ php test.php foo/file.php MyTestCase
...or just a single test method:
$ php test.php foo/file.php MyTestCase::testFoo
Options:
Examples:
$ php test.php -t foo/ $ php test.php -p foo/file.php
Note that you can exclude a test case from a test run by suffixing "__fixture" or "__doNotRun" (double underscore) to the class name.
Strictly speaking, there is only one group that really matters: the full test suite. The more often this is run the better. Although it can be useful to run smaller groups, or even single test methods, this has to be balanced against the unseen effects new code might have on the application as a whole. You could have introduced a problem which won't show up in a limited test run.
For this reason, I don't think there's a need for any particularly sophisticated grouping mechanism. The only one that really matters is already defined: the project dir. Point the runner script at that and it will find everything.
Subgroups are defined simply by the way you've organised files and dirs in the filesystem. If that's not enough, you may not like this script.
If you want to run the Aperiplus test suite, the runner file can be found at: aperiplus/test.php. To run all tests:
$ cd /your/path/to/aperiplus $ php test.php lib/