The structural elements of a PL/Unit test
Each PL/Unit test package can have one or more of the following elements. It should have at least one unit test, the other elements are optional. See the test driven tutorial for an example of the usage of some of these elements.
Each unit test must be a procedure, having no parameters, with a name that begins with "t_". It must be declared in the package specification in order to be treated as a unit test. Each test procedure can have three possible outcomes:
Success - all assertions passed.
Failed - at least one assertion did not pass.
Errored - an unhandled exception was raised from within the test procedure.
Trapping exceptions must be handled very carefully inside unit test procedures. Each PL/Unit assertion will throw the plunit.assertion_failure exception when it fails. If this exception is trapped inside the body of the unit test itself, then the test will appear to pass to the plunit test runner. If you do trap exceptions with a when others clause, then you must also trap the plunit.assertion_failure exception and re-rasie it. For example:
when plunit.assertion_failure then
when others then
-- handle other exceptions here
Setup and Teardown
Each test package can have one setup and one teardown procedure. Setup must be a procedure, having no parameters, and must be named "setup". Teardown must be a procedure, having no parameters, and must be named "teardown". Both procedures must be declared in the package specification.
The Setup procedure is designed to run right before each test procedure in the test package, and Teardown is designed to run after each test procedure is finished. Setup can be useful for creating or modifying data to suit the needs of each unit test. Teardown will run regardless of the outcome of the individual test itself, so passed, failed, and erroneous tests will always call Teardown. Teardown can be useful for performing a rollback of data that may have been inserted, updated, or deleted by the unit test.
Multiple PL/Unit test packages can be tied together to run as a single unit by using suites. A suite is a mechanism for linking one PL/Unit test package to other PL/Unit test packages. To make a test suite, create a procedure named "plunit_suite". This procedure must have no parameters, and be declared in the package specification. In the body of the procedure, making calls to plunit.add_suite will link the current PL/Unit test package to the one specified in the add_suite call. Suites can be nested, so Package A can reference Package B, which can reference Package C. You should not have circular references under any circumstances. PL/Unit will not be able to detect a circular reference, resulting in an endless loop.