Object Oriented Testing

 Find the greatest possible number of errors with a manageable amount of effort applied over a realistic time span.
·         The nature of OO programs changes both testing strategy and testing tactics.
·          Do we need less effort for testing because of greater reuse of design patterns?
·         Answer is no! Binder argues that more testing is needed to obtain high reliability in OO systems, since each reuse is a new context of usage. Testing Object-Oriented Applications: Why is it Different?

·         No sequential procedural executions
·         No structure charts to design integration testing
·         Iterative O-O development and its impact on testing and integration strategies
·         In OO testing begins by evaluating the OOA and OOD models
·         What is Unit?
·         Encapsulation, Inheritance, Polymorphism. 

Criteria for Completion of Testing

·         When are we done testing?
·         _ How to answer this question is still a research question
1.      One view: testing is never done… the burden simply shifts from the developer to the customer
2.      Or: testing is done when you run out of time or money
3.      Or use a statistical model:
− Assume that errors decay logarithmically with testing time
− Measure the number of errors in a unit period
− Fit these measurements to a logarithmic curve
− Can then say: “with our experimentally valid statistical model we have done sufficient testing to say that with 95% confidence the probability of 1000 CPU hours of failure free operation is at least 0.995”.

Testing OO Code

The Structured Testing Pyramid

The OO Testing Pyramid  Testing OOA and OOD Models 

The review of OO analysis and design models is especially useful because the same semantic constructs (e.g., classes, attributes, operations, messages) appear at the analysis, design, and code
level.
Analysis and design models cannot be tested in the conventional sense, because they cannot be
executed.
 Testing O OOA and OOD Models

Formal technical review can be used to examine the correctness and consistency of both analysis and design models.
ü  Correctness:
o   Syntax: Each model is reviewed to ensure that proper modeling conventions have been maintained.
o   Semantic: Must be judged based on the model’s conformance to the real world problem domain by domain experts.
ü  Consistency:
o   May be judged by considering the relationship among entities in the model.
o   Each class and its connections to other classes should be examined.
o   The Class-responsibility-collaboration model can be used.
ü  Completeness
 Model Testing Approaches 

ü  Testing by comparison
compares each model to its predecessor or to previous forms of the model
ü  Testing by inspection
uses checklists to make sure that the model meets certain criteria
ü  Testing by verification
follows certain steps to assure completeness and consistency of one part of the model with another.
 Examples of Analysis and Design Models to be Tested ü  CRC cards
ü  Class specifications
ü  Use cases
ü  State-Transition Models (State Diagram)
ü  State transition diagrams for classes, clusters, and subsystems
ü  Sequence Diagrams.
 Testing the Class Model

CRC Cards: Check that all collaborations are properly represented.
− Example: in a point of sale system.
− A read credit card responsibility of a credit sale class is accomplished if satisfied by a credit card collaborator
ü  Have you tested your analysis and design?
If not, who will do it?
These steps are applied iteratively to each class and through each evolution of the OOA model.

Unit Test

ü  What is a unit?
A single, cohesive function?
A function whose code fits on one page?
The amount of code that can be written in 4 to 40 hours?
Code that is assigned to one person?
ü  We can no longer test a single operation in isolation but rather as part of a class.
ü  In object-oriented programs, a unit is a method within a class.
ü  Smallest testable unit is the encapsulated class.
Methods for Generating Test Cases For Unit Testing 

ü  Statement coverage
ü  _ Graph based
ü  Condition coverage
ü  Path coverage
_ All unit testing methods are also applicable to testing methods within a class.
Class Test Case Design

1.      Identify each test case uniquely
- Associate test case explicitly with the class and/or method to be tested
2. State the purpose of the test
3. Each test case should contain:
a. list of specified states for the object that is to be tested
b. A list of messages and operations that will be exercised as a consequence of the test
c. A list of external conditions for setup (i.e., changes in the environment external to the software that must exist in order to properly conduct the test)
d. Supplementary information that will aid in understanding or implementing the test
− Automated unit testing tools facilitate these requirements.
Challenges of Class Testing OO 

class is the target for test case design.
Encapsulation:− Difficult to obtain a snapshot of a class without building extra methods which display the  classes’ state
Inheritance and polymorphism:− Each new context of use (subclass) requires re-testing because a method may be implemented differently (polymorphism).
− Other unaltered methods within the subclass may use the redefined method and need to be tested
White box tests:− Basis path, condition and loop tests can all apply to individual methods, but don’t test interactions between methods
Integration Testing 

OO does not have a hierarchical control structure so conventional top-down and bottom-up integration tests have little meaning
Integrating operations one at a time into a class is often impossible because of the direct and indirect interactions of the components that make up the class.
_ Integration applied three different incremental strategies:
− Thread-based testing: integrates classes required to respond to one input or event
− Use-based testing: integrates classes required by one use case
− Cluster testing: integrates classes required to demonstrate one collaboration
    Types of Errors Found During Integration TestingMessaging errors:ü  Failure to meet a requirement, i.e., no method to send or receive a message
ü  Incompatible method and message in sender and receiver
ü  Incorrect instantiation or destruction of objects
 System Testing Software may be part of a larger system. This often leads to “finger pointing” by other system dev teams
ü  Finger pointing defense:
1. Design error-handling paths that test external information
2. Conduct a series of tests that simulate bad data
3. Record the results of tests to use as evidence
_ Types of System Testing:
− Recovery testing: how well and quickly does the system recover from faults
− Security testing: verify that protection mechanisms built into the system will protect from unauthorized access (hackers, disgruntled employees, fraudsters)
− Stress testing: place abnormal load on the system
− Performance testing: investigate the run-time performance within the context of an integrated system
 All rules and methods of traditional systems
testing are also applicable applicable to object-oriented.
_ Use cases provide a more precise mechanism for writing test cases.
 Automated Testing

ü  Junit at Junit.org
ü  CPPUnit on SourceForge.net,
ü  NUnit for .Net
ü  Rational Robot.

OO Testing Methodology  Stages of Test [RUP]_ Developer Testing

_ Unit Test
_ Integration Test
_ System Test
_ Acceptance Test
 Test Planning [RUP]

ü  What iteration you are in?
ü  What stage of test (unit test, integration test, system test) you are performing?
ü  Types of test (functional, stress, volume, performance, usability, distribution, and so on).
ü  Evaluation criteria used (code-based test coverage, requirements-based test coverage, number of defects, mean time between failure, and so on.)
ü  Testing techniques used (manual and automated).
 Completion Criteria [RUP]