confusa

Introduction
The framework is inteded to do the following:

• Encourage referential transparency in the code.
• Help identify and remove reported bugs
• Avoid re-introducing bugs (as it should be a test for it)

As a rule of thumb: it should be possible to write a complete test based on the function documentation (that describes what a given function should do). Of course, not everything can be tested reliably, as some parts must change the state of the portals, or affects how the portal renders in the browser.

Test-framework construction

Basic principles

1. All tests inherits from Test.php
2. All tests are placed in a file named after the follwing convention: Test_Module.php
3. Each testmodule tests only a very narrow, predefined set of cases, and the name should reflect where in the source-library the submodule being tested can be found.
4. A test should not output anything to stdout if things work as expected. If a test fails, it is encouraged to output the reason along with a possible explanation.
5. A test can access files, these files must be placed in tests/files/test_name

Invoking the test

To make the test as easy to use as possible, the main route will look at the directory and import all files starting with “Test_” and ending with “.php”, and then making an instance of an object with the same name. The following code is a subset, for a complete rundown, see run_tests.php:

if (preg_match('/^Test_.*\.php$/', $file)) {
        require_once $file;
        $objname =  substr($file, 0, -4);
        $t = new $objname;
        $res = $t->runTests();
}

Running the tests

An example is worth more than a 1000 pictures.

[ 10:11 ] henrikau@brutus:~/dev/confusa/tests {master} $ php -f run_tests.php
Running tests:
Making directory
Input:                                  [   OK   ]
Miscellaneous:                          [   OK   ]

Adding new tests

The Test-API:

• __construct the constructor expects the name of the test. This name should be short (less than 48 characters), and be descriptive of the test.
• getFile(‘filename’) a function that should be used if the test requires files to perform the test. For instance, to test if a certificate-hash is computed directly, the test needs a certificate and a pre-computed hash that is known to be correct.
• printMsg(‘msg’) the preferred function for printing text. This will prefix the output with [name] in order to make the output more traceable.
• runTests() the abstract function that all subclasses must implement. When the tests are run, the main machinery will call this function.

Example test

This will show the skeleton-code in Miscallenous (as seen in the previous section), a dummy, skeleton test created for illustrative purposes.

<?php
  /* Test will include confusa_include.php, giving access to the entire
   * source-tree (except tests/) */
require_once 'Test.php';
class Test_Misc extends Test
{
        function __construct()
        {
                parent::__construct("Miscellaneous");
        }

        public function runTests()
        {
                if (!$this->valid) {
                        return false;
                }
                $res=true;
                return $res;
        }
} /* end Test_Misc */
?>