Unit Test Functions Procedures Classes and Methods as

Unit Test: Functions, Procedures, Classes, and Methods as Units

The unit test is the lowest level of testing performed during software development where individual units of software tested in isolation from other parts of a program. Since the software component being tested is relatively small in size and simple in function, it is easier to design, execute, record, and analyze test results. If a defect is revealed by the tests it is easier to locate and repair since only the one unit is under consideration.

In a conventional structured programming language, such as C, the unit to be tested is traditionally the function or sub-routine. In object oriented languages such as C++, the basic unit to be tested is the class.

Organizational Approaches Top Down Testing Bottom Up Testing Isolation Testing

Top Down Testing

Stubs: Stubs are dummy modules which are known as "called programs" which is used in integration testing (top down approach), used when sub programs are under construction. Drivers: Drivers are also kind of dummy modules which are known as "calling programs", which is used in bottom up integration testing, used when main programs are under construction. Stub means a Dummy model of a particular module. Real Life Example: Suppose we have to test the integration between 2 modules A and B and we have developed only module A while Module B is yet in development stage. So in such case we can not do integration test for module A but, if we prepare a dummy module, having similar features like B then using that we can do integration testing. Our main aim in this is to test Module A & not Module B so that we can save time otherwise we have to wait till the module B is actually developed. Hence this dummy module B is called as Stub. Now module B cannot send/receive data from module A directly/automatically so, in such case we have to transfer data from one module to another module by some external features. This external feature used is called Driver.

Bottom up Testing

Test Design Test design consists of following stages: Test strategy Test planning Test specification Test procedure

Developing Unit Test Specifications Each unit test case should include four essential elements: A statement of the initial state of the unit, the starting point of the test case The inputs to the unit What the test case actually tests, in terms of the functionality of the unit and the analysis used in the design of the test case The expected outcome of the test case

Step 1 - Make it Run The purpose of the first test case in any unit test specification should be to execute the unit under test in the simplest way possible. Suitable techniques: Specification derived tests Equivalence partitioning

Six step general process for developing a unit test specification as a set of individual unit test cases. Step Step 1 2 3 4 5 6 - Make it Run Positive Testing Negative Testing Special Considerations Coverage Tests Coverage Completion

Step 2 - Positive Testing Test cases should be designed to show that the unit under test does what it is supposed to do. Suitable techniques: Specification Equivalence derived tests partitioning State-transition testing

Step 3 - Negative Testing Test cases should be enhanced and further test cases should be designed to show that the software does not do that it is not supposed to do. Suitable techniques: Error guessing Boundary value analysis Internal boundary value testing State-transition testing

Step 4 - Special Considerations Where appropriate, test cases should be designed to address issues related to performance, safety and security requirements. Suitable techniques: Specification derived tests

Step 5 - Coverage Tests Add more test cases to the unit test specification to achieve specific test coverage objectives. Suitable techniques: Branch testing Condition testing Data definition-use testing State-transition testing

Test Execution At this point the test specification can be used to develop an actual test procedure and executed. Execution of the test procedure will identify errors in the unit which can be corrected and the unit re-tested. Running of test cases will indicate whether coverage objectives have been achieved. If not…

Step 6 - Coverage Completion Where coverage objectives are not achieved, analysis must be conducted to determine why. Failure to achieve a coverage objective may be due to: Infeasible paths or conditions Unreachable Insufficient or redundant code test cases

Specification Derived Tests Test cases are designed by walking through the relevant specifications. Each test case should test one or more statements of specification. Positive test case design technique.

Example Specification Input - real number Output - real number When given an input of 0 or greater, the positive square root of the input shall be returned. When given an input of less than 0, the error message "Square root error - illegal negative input" shall be displayed and a value of 0 returned.

Equivalence Partitioning It is based upon splitting the inputs and outputs of the software under test into a number of partitions Test cases should therefore be designed to test one value in each partition. Still positive test case design technique.

Boundary Value Analysis Similar to Equivalence Partitioning Assumes that errors are most likely to exist at the boundaries between partitions. Test cases are designed to exercise the software on and at either side of boundary values. Incorporates a degree of negative testing into the test design

State-Transition Testing Used where the software has been designed as a state machine Test cases are designed to test transition between states by generating events Negative testing can be done by using illegal combinations of states and events

Branch Testing Designed E. g. to test the control flow branches if-then-else

Condition Testing Used to complement branch testing It tests logical conditions E. g. while(a<b), for

Error Guessing Based solely on the experience of the test designer The test cases are designed for the values which can generate errors If properly implemented it can be the most effective way of testing

Summary Unit testing provides the earliest opportunity to catch the bugs And fixing them at this stage is the most economical Mainly three organizational approaches to Unit Testing Whatever approach we take unit test cases should be developed before the code Six step process to develop the test specifications Black Box and White Box techniques to develop individual test cases

Unit Test: The Need for Preparation Goal of unit testing To insure that each individual software unit is functioning according to its specification. Good testing practice calls for unit tests that are planned and public. Planning includes designing tests to reveal defects such as functional description defects, algorithmic defects, data defects, and control logic and sequence defects. Resources should be allocated, and test cases should be developed, using both white and black box test design strategies. The unit should be tested by an independent tester (someone other than the developer) and the test results and defects found should be recorded as a part of the unit history. Each unit should also be reviewed by a team of reviewers, preferably before the unit test.

To prepare for unit test the developer/tester must perform several tasks. These are: (i) plan the general approach to unit testing; (ii) design the test cases, and test procedures (these will be attached to the test plan); (iii) define relationships between the tests; (iv) prepare the auxiliary code necessary for unit test.

Unit Test Planning 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.

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 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. Phase 3: Add Levels of Detail to the Plan 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.