Test Suite Code Management

More formal rules should be used for managing the source code of formal tests. This document defined the rules that should be followed.

Change Reviews

Code changes should be sent to the mailing list for approval. 2 days should be allowed for comments, after which time, the change may be committed if there were not issues raised. Code changes that alter the method used to implement a test should be given heavier consideration and evaluated against the definition of the assertion and test cases involved.

Functional Changes

Functional changes to existing code should be considered carefully. Functional changes should not change the intended result of a test.

New Features

New features should be developed following the formal process of test suite development as summarized here

• The specification of the feature being tested shall be identified. The specification should be largely complete, with some maturity, but need not be formally approved as a Standard yet.
• For each entity (ie function) in the Specification, a list of assertions shall be created and reviewed.
• For each assertion, a list of test cases shall be created and reviewed.
• For each test case, write code to implement the test.

New features shall be clearly marked as "in-progress" until they are complete, and approved by the Testing Group for use as a part of the formal test suite.