2 Unit Test - Why?
3 Unite Test - When?
4 Unit Test - How? (method, technique)
Unit Test – What
Unit Testing Actions:
Validate that individual units of software program are working properly
A unit is the smallest testable part of an application (In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is always a method)
Units are distinguished from modules in that modules are typically made up of units
Unit Testing Deliverables:
Tested software units
Related documents (Unit Test case, Unit Test Report)
Unit Test – Why ?
Ensure quality of software unit
Detect defects and issues early
Reduce the Quality Effort & Correction Cost
Unit Test – When ?
After Coding
Before Integration Test
Unit testing
Modules can be tested statically or dynamically
A basis path set will execute every independent path through a module
Modules can be instrumented to gather statistics on their execution
Modules can be unit tested top-down, bottom-up or in isolation
Test drivers and stubs are required to unit test modules
=> The motivation is to ensure that value is not added to defective products
Source code reviews (static testing)
Everyone’s code is reviewed
Do not review code to measure individual performance
Drawing a flow graph and calculating complexity could be used as part of the inspection
Portability and maintainability can be given special attention during reviews
Unit testing (Dynamic testing)
Functional test cases
Black box test cases
Structural test cases
White box test cases
Steps to develop a basis set of a module:
Create annotated Pseudo code
Draw Control Flow Graph
Select a baseline path through the program (should be the most common paths that is followed)
A second path is added by varying the outcome of the first decision along the baseline path while keeping all of the other decision outcomes as same as the baseline path
This process is repeated until all of the decisions along the baseline path have had their outcomes altered.
The number of paths in a basis set is always equal to the cyclomatic complexity of the module
Unit testing strategy
- Start with simple tests that get the module running;
- Run functional tests designed to validate that the module does what it is supposed to (positive test);
- Run negative tests that are designed to make the
module fail;
- Run tests associated with specific ISO 9126 quality attributes (performance, security, etc.) if required; and finally
- Add additional structurally tests to complete a basis set that achieves coverage of all independent paths;
Unit testing strategy (cont.)
- Both Functional and structural test techniques identify positive test cases
- Negative tests are designed to demonstrate that a module does not work as expected. Unfortunately,
there are no simple techniques for identifying negative test cases. Error guessing, based on experience, remains the best approach.
- Some common types of error include:
Array sizes;
Counter maximums;
Physical boundaries;
Variable field sizes;
Arithmetic operation;
Switch variable values;
Pointer variables; and
Null values.
Order of Testing modules
Top-Down Unit Testing: stubs are required
Bottom-up Unit Testing: drivers are required
Isolation Unit Testing: drivers and stubs are required for each module
Advantages and Disadvantages
Unit Test – How? Techniques
Black box test (Functional)
• Specification derived tests
• Equivalence partitioning
• Boundary value analysis
White box (Structural)
• Statement coverage
• Decision (branch) coverage
• Path coverage
Unit Test – Black box technique
Black-box testing
Functional testing: ensure each unit acts right as its design
Business testing: ensure the software program acts right as user requirement
Unit Test –White box technique
White-box testing
Check syntax of code by compiler to avoid syntax errors
Run code in debug mode, line by line, through all independent paths of program to ensure that all statement of codes has been executed at least one time
Examine local data structure to ensure that data stored temporarily maintains its integrity during all all steps of code execution
Check boundary conditions to ensure that code will run properly at the boundaries established as requirements
Review all error handling paths
BBT – Specification derived test
You can choose all or some statements in the specification of software
Create test cases for each statements of specification
Execute test cases to check test result will output as the specification
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.
Example Test Cases
Test Case 1: Input 4, Return 2
Use the first statement in the specification
("When given an input of 0 or greater, the positive square root of the input shall be returned.").
Test Case 2: Input -10, Return 0, Output "Square root error - illegal negative input“
Use the second and third statements in the specification
("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.”).
BBT: Equivalence partitioning
Divide the input of a program into classes of data from which test cases can be derived. This might help you to reduce number of test cases that must be developed.
Behavior of software is equivalent for any value within particular partition
A limited number of representative test cases should be chosen from each partition
Example Test Cases
WBT: Statement Coverage
WBT: Path Coverage
Example: White box test case
White box test: Comparison
Unit Testing Tools
