Designing Unit Test Cases
Vivek Gulati
COMP595VAV
Dept. of Computer Science
California State University, Northridge
Designing Unit Test Cases
 Copyright of IPL, Information
Processing Ltd
 IPL is an independent software house
founded in 1979 and based in Bath
 IPL has developed and supplies the
AdaTEST and Cantata software
verification products.
 AdaTEST and Cantata have been
produced to these standards.
Contents
 Why Unit Test?
 Organizational Approaches for Unit
Testing
 Designing Unit Test Cases
 Development of test specification
 Test case design techniques
 Conclusion
Contents
 Why Unit Test?
 Organizational Approaches for Unit
Testing
 Designing Unit Test Cases
 Development of test specification
 Test case design techniques
 Conclusion
What is Unit Testing?
 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.
What is Unit Testing?
 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.
Popular Misconceptions
 It Consumes Too Much Time
 It Only Proves That the Code Does
What the Code Does
 “I'm too Good a Programmer to Need
Unit Tests”
 Integration Tests will Catch all the
Bugs Anyway
 It is not Cost Effective
Some Figures
Contents
 Why Unit Test?
 Organizational Approaches for
Unit Testing
 Designing Unit Test Cases
 Development of test specification
 Test case design techniques
 Conclusion
Organizational Approaches
 Top Down Testing
 Bottom Up Testing
 Isolation Testing
Top Down Testing
Advantages
 Early integration of units before the
software integration phase.
 Development time can be shortened
by overlapping unit testing with the
detailed design and code phases of
the software lifecycle.
Disadvantages
 Because
of
stubs
testing
is
complicated and expensive to develop
and maintain.
 Changes to a unit often impact the
testing of sibling units and units
below it in the hierarchy.
Bottom up Testing
Advantages
 Early integration of units before the
software integration phase.
 Only test drivers are required. This
can make unit tests near the bottom
of the unit hierarchy relatively simple.
Disadvantages
 As testing progresses up the unit hierarchy,
testing becomes more complicated, and
expensive.
 Changes to a unit often impact the testing
of units above it in the hierarchy.
 The first units to be tested are the last
units to be designed, so unit testing cannot
overlap with the detailed design phase of
the software lifecycle.
Isolation Testing
Advantages
 It is easier to test an isolated unit
 Drivers and stubs simpler as only one
unit is being tested
 Changes to a unit does not impact other
units.
Contents
 Why Unit Test?
 Organizational Approaches for Unit
Testing
 Designing Unit Test Cases
 Development of test specification
 Test case design techniques
 Conclusion
Test Design
 Test design
stages:




Test
Test
Test
Test
consists
strategy
planning
specification
procedure
of
following
Contents
 Why Unit Test?
 Organizational Approaches for Unit
Testing
 Designing Unit Test Cases
 Development of test specification
 Test case design techniques
 Conclusion
Developing Unit Test
Specifications
 Tests should be designed before the
code is written.
 A unit test specification comprises a
sequence of unit test cases.
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
Developing Unit Test
Specifications
 Six step general process for
developing a unit test specification as
a set of individual unit test cases.






Step
Step
Step
Step
Step
Step
1
2
3
4
5
6
-
Make it Run
Positive Testing
Negative Testing
Special Considerations
Coverage Tests
Coverage Completion
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
Developing Unit Test
Specifications
 Six step general process for
developing a unit test specification as
a set of individual unit test cases.






Step
Step
Step
Step
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 derived tests
 Equivalence partitioning
 State-transition testing
Developing Unit Test
Specifications
 Six step general process for
developing a unit test specification as
a set of individual unit test cases.






Step
Step
Step
Step
Step
Step
1
2
3
4
5
6
-
Make it Run
Positive Testing
Negative Testing
Special Considerations
Coverage Tests
Coverage Completion
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
Developing Unit Test
Specifications
 Six step general process for
developing a unit test specification as
a set of individual unit test cases.






Step
Step
Step
Step
Step
Step
1
2
3
4
5
6
-
Make it Run
Positive Testing
Negative Testing
Special Considerations
Coverage Tests
Coverage Completion
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
Developing Unit Test
Specifications
 Six step general process for
developing a unit test specification as
a set of individual unit test cases.






Step
Step
Step
Step
Step
Step
1
2
3
4
5
6
-
Make it Run
Positive Testing
Negative Testing
Special Considerations
Coverage Tests
Coverage Completion
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…
Developing Unit Test
Specifications
 Six step general process for
developing a unit test specification as
a set of individual unit test cases.






Step
Step
Step
Step
Step
Step
1
2
3
4
5
6
-
Make it Run
Positive Testing
Negative Testing
Special Considerations
Coverage Tests
Coverage Completion
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
Step 6 - Coverage Completion
 Some insight into the code is
required to achieve coverage targets.
 Suitable techniques:
 Branch testing
 Condition testing
 Data definition-use testing
 State-transition testing
Contents
 Why Unit Test?
 Organizational Approaches for Unit
Testing
 Designing Unit Test Cases
 Development of test specification
 Test case design techniques
 Conclusion
Test Case Design Techniques
 Black box (functional)




Specification derived tests
Equivalence partitioning
Boundary value analysis
State-transition testing




Branch testing
Condition testing
Data definition-use testing
Internal boundary value testing
 White box (structural)
 Other
 Error guessing
Test Case Design Techniques
 Black box (functional)




Specification derived tests
Equivalence partitioning
Boundary value analysis
State-transition testing
 White box (structural)
 Other
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.
 The library routine Print_Line shall be used to
display the error message.
Example Test Cases
 Test Case 1: Input 4, Return 2
 Exercises 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“ using Print_Line.
 Exercises 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. The library routine Print_Line shall be
used to display the error message.").
Test Case Design Techniques
 Black box (functional)




Specification derived tests
Equivalence partitioning
Boundary value analysis
State-transition testing
 White box (structural)
 Other
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.
Example Partitions &
Test Cases
Test Case Design Techniques
 Black box (functional)




Specification derived tests
Equivalence partitioning
Boundary value analysis
State-transition testing
 White box (structural)
 Other
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
Example Boundaries
Example Boundary Test Cases
Test Case Design Techniques
 Black box (functional)




Specification derived tests
Equivalence partitioning
Boundary value analysis
State-transition testing
 White box (structural)
 Other
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
Test Case Design Techniques
 Black box (functional)
 White box (structural)




Branch testing
Condition testing
Data definition-use testing
Internal boundary value testing
 Other
Branch Testing
 Designed to test the control flow
branches
 E.g. if-then-else
Test Case Design Techniques
 Black box (functional)
 White box (structural)




Branch testing
Condition testing
Data definition-use testing
Internal boundary value testing
 Other
Condition Testing
 Used to complement branch testing
 It tests logical conditions
 E.g. while(a<b), for(;;)
Test Case Design Techniques
 Black box (functional)
 White box (structural)




Branch testing
Condition testing
Data definition-use testing
Internal boundary value testing
 Other
Data Definition-Use Testing
 Test cases to test pairs of data
definitions and uses.
Test Case Design Techniques
 Black box (functional)
 White box (structural)




Branch testing
Condition testing
Data definition-use testing
Internal boundary value testing
 Other
Internal Boundary Value
Testing
 Implements test cases when
boundaries and partitions can only be
established by looking at the code
Example Internal Boundary
Test Cases
 Test Case 1: Error just greater than
the desired accuracy
 Test Case 2: Error equal to the
desired accuracy
 Test Case 3: Error just less than the
desired accuracy
Test Case Design Techniques
 Black box (functional)
 White box (structural)
 Other
 Error guessing
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
Contents
 Why Unit Test?
 Organizational Approaches for Unit
Testing
 Designing Unit Test Cases
 Development of test specification
 Test case design techniques
 Summary
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
Thank You
Questions?
Descargar

Designing Unit Test Cases - College of Engineering and