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 are 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 When developing a strategy for unit testing, there are three basic organizational approaches that can be taken. Top down, Bottom Up and Isolation.

Top Down Testing In top down testing the unit at the top of the hierarchy is tested first. All called units are replaced by stubs. As the testing progresses the stubs are replaced by actual units. Top down testing requires test stubs, but not test drivers. In the given example unit D is being tested and ABC have already been tested. All the units below D have been replaced by test stubs. In top down testing units are tested from top to bottom. The units above a unit are calling units and below are the called units. The units below the unit being tested are replaced by stubs. As the testing progresses stubs are replaced by actual units

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 In bottom up testing the lowest level units are tested first. They are then used to test higher level units. The process is repeated until you reach the top of the hierarchy. Bottom up testing requires test drivers but does not require test stubs. In the example unit d is the unit under test and all the units below it have been tested and it is being called by test drivers instead of the units above it.

Test Design Test strategy Test planning Test specification Test design consists of following stages: Test strategy Test planning Test specification Test procedure A test design should consist of these stages. i.e. Test Strategy, Test Planning, Test Specification, Test Procedure. These four stages apply to all levels of testing including the unit testing. Test strategy and test planning are mainly project management activities and Test procedure is the actual implementation of the test.

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 Or the setup condition from where a test case will start. The data input to the unit A detailed functionality and analysis of the test case The expected outcome..i.e. what do we expect when the test case ends

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 The purpose of the first test case in any unit test specification should be to just run the unit in the simplest way. When the tests are actually executed, knowing that at least the first unit test will execute is a good confidence boost. If it will not execute, then it is preferable to have something as simple as possible as a starting point for debugging.

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

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 derived tests Equivalence partitioning State-transition testing The test designer should walk through the relevant specifications; each test case should test one or more statements of specification. Where more than one specification is involved, it is best to make the sequence of test cases correspond to the sequence of statements in the primary specification for the unit.

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 The existing test cases should be modified to show that the software does not do what it is not supposed to do. This step depends primarily upon error guessing, relying upon the experience of the test designer to anticipate problem areas.

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 All software requirements have some special conditions which address the issue of safety, security and performance. In step 4 the test cases should be modified or developed to address these issues. Particularly in the cases of safety and security, it can be convenient to give test cases special emphasis to facilitate security analysis or safety analysis and certification. Test cases already designed which address security issues or safety hazards should be identified in the unit test specification. Further test cases should then be added to the unit test specification to ensure that all security issues and safety hazards applicable to the unit will be fully addressed.

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 Visualize the coverage likely to be achieved by the designed test case. The test coverage likely to be achieved by the designed test cases should be visualized Once coverage tests have been designed, the test procedure can be developed and the tests executed.

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… A test specification designed using the above five steps should in most cases provide a thorough test for a unit. There is therefore a further coverage completion step in the process of designing test specifications.

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 or redundant code Insufficient test cases Infeasible paths or conditions - the corrective action should be to annotate the test specification to provide a detailed justification of why the path or condition is not tested. the corrective action will probably be to delete the offending code. It is easy to make mistakes in this analysis, particularly where defensive programming techniques have been used. If there is any doubt, defensive programming should not be deleted. test cases should be refined and further test cases added to a test specification to fill the gaps in test coverage.

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 to test the control flow branches E.g. 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.

(iii) define relationships between the tests; 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.

Phase 1: Describe Unit Test Approach and Risks 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.