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

2. 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.

3. 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.

4. 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.

5. 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

6. 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.

7. 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.

8. 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.

9. 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

10. 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.

11. 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

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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

22. 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

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

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

25. 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

26. 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

28. 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.

29. (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.

30. 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.

31. 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.

32. 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.