Test.Unit

Test.Unit: Declarative API test framework

• Objective of Test.Unit is to simplify test creation through as much definitional programming as possible. Instead of the classical call and ok tests, Test.Unit asks the programmer to specify lists of inputs and their corresponding expected outputs as simply as possible. Test.Unit takes care of calling the methods on the correct objects, catching exceptions and other semantic errors (method not found) for the programmer.

• Excerpt from Date.bunit, a simple Type.Date unit test:

Type();
DateTime()->set_test_now('1/1/1900 12:0:0', req());
[
    class() => [
        now => '2415021 79199',
        from_datetime => [
            '2453740 44700' => '2453740 79199',
        ],
        from_literal => [
            '1/1/1850' => '2396759 79199',
            '1/2/1800' => '2378498 79199',
        ],
        to_parts => [
            class()->local_today =>
                [59, 59, 21, 1, 1, 1900],
        ],
    ],
];

• All unit tests have a "type", which is specified by the first class call, e.g., Type() above, in the bunit file.

• The type is followed by arbitrary perl code to setup the execution context. In this example, the time is set to a well-known value so the test assume time is constant.

• The return value of a bunit is an array_ref, which is typically structured in three nested parts (from outermost to innermost):

  1. Objects - the call to class() above returns the current class (implicitly identified by the name of the file, which is Date.bunit, in the Bivio/Type/t directory).

  2. Methods - the object(s) are followed by an array_ref of methods to call.

  3. Cases - The methods are followed by an array_ref of pairs of inputs (left) and expected outputs (right). Since perl methods accept and return lists, the parameters and expected values are array_refs in the simple case.