4.5 Procedure for Unit Testing

Entry criteria: A unit must have undergone Informal Testing (see section 1.5) by the author. This ensures that the unit compiles and has a good chance of passing all the unit tests. It also provides a chance for the person most familiar with the code (the author) to test it.

Exit criteria: Since a class may be in a development stage during Unit Testing, it may not yet have full functionality. As such, it is not expected that a class will pass all of its unit tests before it is finished. Therefore, each class only needs to pass all unit tests that it had previously passed in order to meet the exit criteria for unit testing. That is, a test that produced a pass in a previous version of code must produce a pass in all later versions. A class cannot be considered finished however, unless it has passed all of its unit tests.

The procedure for Unit Testing is as follows:

1. At the time an author is assigned to write a class (or even before), a unit tester is also assigned to write the unit tests for that class.
2. As unit tests are finished, they are made available to the author to assist in Informal Testing.
3. The author must carry out Informal Testing on the class while it is written. The Informal Testing may make use of the Unit Tests that have been written and also any test data the author thinks appropriate.
4. Once a class has been changed and is ready for formal testing, the author must use the runtests script as described in section 1.7 to run Unit Tests on the class. The script will copy the class into the stubs directory (see 4.1) and then run all the unit tests that are available for that class.
5. The class must pass all test cases that it had previously passed (as explained above). If not, then the author must stop and fix the class (or the test case if the interface to the class has changed) to ensure this.
6. A Unit Testing Report (see section 4.6) is created by the author by running the unit tests.
7. Once the report has been created and stored under /test-reports/sam/unit, the changes may be checked into CVS.

Any time a class in CVS changes (source code only, not documentation changes) and is therefore re-tested (for example, during Integration or System Testing), another Unit Testing Report must be created, and the changes posted for review as above.