# 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|http://lists.x.org/mailman/listinfo/xorg-test]] 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.