Unit test planning
A general unit test plan should be prepared. It may be prepared as a component of the master test plan or as a stand-alone plan. It should be developed in conjunction with the master test plan and the project plan for each project. Documents that provide inputs for the unit test plan are the project plan, as well the requirements, specification, and design documents that describe the target units. Components of a unit test plan are described in detail the IEEE Standard for Software Unit Testing . This standard is rich in information and is an excellent guide for the test planner. A brief description of a set of development phases for unit test planning is found below. In each phase a set of activities is assigned based on those found in the IEEE unit test standard . The phases allow a steady evolution of the unit test plan as more information becomes available. The reader will note that the unit test plan contains many of the same components as the master test plan that will be described in Chapter 7. Also note that a unit test plan is developed to cover all the units within a software project; however, each unit will have its own associated set of tests.
Phase 1: Describe Unit Test Approach and Risks
In this phase of unit testing planning the general approach to unit testing is outlined. The test planner:
(i) identifies test risks;
(ii) describes techniques to be used for designing the test cases for the units;
(iii)describes techniques to be used for data validation and recording of test results;
(iv) describes the requirements for test harnesses and other software that interfaces with the units to be tested, for example, any special objects needed for testing object- oriented units.
During this phase the planner also identifies completeness requirement what will be covered by the unit test and to what degree (states, functionality, control, and data flow patterns). The planner also identifies termination conditions for the unit tests. This includes coverage requirements, and special cases. Special cases may result in abnormal termination of unit test (e.g., a major design flaw). Strategies for handling these special cases need to be documented. Finally, the planner estimates resources needed for unit test, such as hardware, software, and staff, and develops a tentative schedule under the constraints identified at that time.
Phase 2: Identify Unit Features to be Tested
This phase requires information from the unit specification and detailed design description. The planner determines which features of each unit will be tested, for example: functions, performance requirements, states, and state transitions, control structures, messages, and data flow patterns. If some features will not be covered by the tests, they should be mentioned and the risks of not testing them be assessed. Input/output characteristics associated with each unit should also be identified, such as variables with an allowed ranges of values and performance at a certain level.
Phase 3: Add Levels of Detail to the Plan
In this phase the planner refines the plan as produced in the previous two phases. The planner adds new details to the approach, resource, and scheduling portions of the unit test plan. As an example, existing test cases that can be reused for this project can be identified in this phase. Unit availability and integration scheduling information should be included in the revised version of the test plan. The planner must be sure to include a description of how test results will be recorded. Test-related documents that will be required for this task, for example, test logs, and test incident reports, should be described, and references to standards for these documents provided. Any special tools required for the tests are also described. The next steps in unit testing consist of designing the set of test cases, developing the auxiliary code needed for testing, executing the tests, and recording and analyzing the results.