Designing the unit tests

Designing the unit tests

Part of the preparation work for unit test involves unit test design. It is important to specify

(i) the test cases (including input data, and expected outputs for each test case), and, (ii) the test procedures (steps required run the tests). These items are described in more detail in Chapter 7. Test case data should be tabularized for ease of use, and reuse. Suitable tabular formats for test cases are found in Chapters 4 and 5. To specifically support object-oriented test design and the organization of test data, Berard has described a test case specification notation. He arranges the components of a test case into a semantic network with parts, Object_ID, Test_Case_ID, Purpose, and List_of_Test_Case_Steps. Each of these items has component parts. In the test design specification Berard also includes lists of relevant states, messages (calls to methods), exceptions, and interrupts. As part of the unit test design process, developers/testers should also describe the relationships between the tests. Test suites can be defined that bind related tests together as a group. All of this test design information is attached to the unit test plan. Test cases, test procedures, and test suites may be reused from past projects if the organization has been careful to store them so that they are easily retrievable and reusable.

Test case design at the unit level can be based on use of the black and white box test design strategies described in Chapters 4 and 5. Both of these approaches are useful for designing test cases for functions and procedures. They are also useful for designing tests for the individual methods (member functions) contained in a class. Considering the relatively small size of a unit, it makes sense to focus on white box test design for procedures/functions and the methods in a class. This approach gives the tester the opportunity to exercise logic structures and/or data flow sequences, or to use mutation analysis, all with the goal of evaluating the structural integrity of the unit. Some black box-based testing is also done at unit level; however, the bulk of black box testing is usually done at the integration and system levels and beyond. In the case of a smaller-sized COTS component selected for unit testing, a black box test design approach may be the only option. It should be mentioned that for units that perform mission/safely/business critical functions, it is often useful and prudent to design stress, security, and performance tests at the unit level if possible.