Chapter 9 Object Oriented Testing

Objectives lTo cover the strategies and tools associated with object oriented testing  Analysis and Design Testing  Class Tests  Integration Tests  System Tests  Validation Tests analysis designcodetest

A Broader View of Testing lNature of OO systems influence both testing strategy and methods lWill re-use mean less need for testing? NO lIn Object Oriented systems the view of testing is broadened to encompass Analysis and Design l“It can be argued that 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.” lAllows early circumvention of later problems

Object-Oriented Testing lAnalysis and Design:  Testing begins by evaluating the OOA and OOD models  Cannot be executed, so conventional testing impossible  Use formal technical reviews of correctness, completeness and consistency lProgramming:  OO Code testing differs from conventional methods: lThe concept of the ‘unit’ broadens due to class encapsulation lIntegration focuses on classes and their execution across a ‘thread’ or in the context of a usage scenario lValidation uses conventional black box methods  Test case design draws on conventional methods, but also encompasses special features

Criteria for Completion of Testing lWhen are we done testing? 1.Testing is never done, the burden simply shifts from you to the customer 2.Testing is done when you run out of time or money 3.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” lMore research needs to be done into how to answer this question

Strategic Issues lIssues to address for a successful software testing strategy:  Specify product requirements in a quantifiable manner long before testing commences. For example, portability, maintainability, usability  State testing objectives explicitly. For example, mean time to failure, test coverage, etc  Understand the users of the software and develop a profile for each user category. Use cases do this  Develop a testing plan that emphasizes “rapid cycle testing”. Get quick feedback from a series of small incremental tests  Build robust software that is designed to test itself. Exception handling and automated testing  Conduct formal technical reviews to assess the test strategy and test cases themselves. “Who watches the watchers”  Develop a continuous improvement approach to the testing process

Testing Analysis and Design lSyntactic correctness:  Is UML notation used correctly? lSemantic correctness:  Does the model reflect the real world problem?  Is UML used as intended by its designers? lTesting for consistency:  Are different views of the system in agreement?  An inconsistent model has representations in one part that are not correctly reflected in other portions of the model

Testing the Class Model 1.Revisit the CRC model and the object-relationship model. Check that all collaborations are properly represented in both 2.Inspect the description of each CRC index card to determine if a delegated responsibility is part of the collaborator’s definition  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 3.Invert the connection to ensure that each collaborator that is asked for a service is receiving requests from a reasonable source  Example: a credit card being asked for a purchase amount (a problem)

Final Steps in Testing the Class Model 4.Using the inverted connections examined in step 3, determine whether other classes might be required or whether responsibilities are properly grouped among the classes 5.Determine whether widely requested responsibilities might be combined into a single responsibility  Example: read credit card and get authorization could easily be grouped into validate credit request 6.Steps 1 to 5 are applied iteratively and repeatedly

Testing OO Code class tests integrationtests validationtests systemtests

[1] Class Testing lSmallest testable unit is the encapsulated class lA single operation needs to be tested as part of a class hierarchy because its context of use may differ subtly lClass testing is the equivalent of unit testing in conventional software lApproach:  Methods within the class are tested  The state behavior of the class is examined lUnlike conventional unit testing which focuses on input- process-output, class testing focuses on designing sequences of methods to exercise the states of a class lBut white-box methods can still be applied

Class Testing Process class to be tested test cases results softwareengineer

Class Test Case Design 1.Each test case should be uniquely identified and should be explicitly associated with the class to be tested 2.The purpose of the test should be stated 3.A list of testing steps should be developed for each test and should contain: a.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 exceptions that may occur as the object is tested d.A list of external conditions (i.e., changes in the environment external to the software that must exist in order to properly conduct the test) e.Supplementary information that will aid in understanding or implementing the test

Challenges of Class Testing lEncapsulation:  Difficult to obtain a snapshot of a class without building extra methods which display the classes’ state lInheritance:  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 lWhite box tests:  Basis path, condition, data flow and loop tests can all be applied to individual methods within a class but they don’t test interactions between methods

Challenges of Class Testing lEncapsulation: Class Employee { String Name; (Data section) Number EmpSal; Date Dateofjoining; Number EmpNum; Function GetSalary(EmpNum) { Connect to database; Get Salary for EmpNum; Return EmpSal; } Function SetSalary(NewSalary) { Connect to database; Change EmpNum salary with new salary; }

lEncapsulation: Public void main ( ) { Salary = GetSalary (EmpNum) New Salary = Salary + IncrementAmt; SetSalary (New Salary); } Challenges of Class Testing

Random Class Testing  Random is black box software testing technique, tested by generating random, independent inputs.  Requires large number of data permutations & combinations  Can very inefficient Input random [123,36,-35,48,0] Example int myAbs (int x) { if (x > 0) { return x; } else { return x; }

Partition Class Testing lReduces the number of test cases required (similar to equivalence partitioning) lState-based partitioning  Categorize and test methods separately based on their ability to change the state of a class  Example: deposit and withdraw change state but balance does not lAttribute-based partitioning  Categorize and test operations based on the attributes that they use  Example: attributes balance and creditLimit can define partitions lCategory-based partitioning  Categorize and test operations based on the generic function each performs  Example: initialization (open, setup), computation (deposit, withdraw), queries (balance, summarize), termination (close)

[2] Integration Testing lOO does not have a hierarchical control structure so conventional top-down and bottom-up integration tests have little meaning lIntegration 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

Random Integration Testing lMultiple Class Random Testing 1.For each client class, use the list of class methods to generate a series of random test sequences. The methods will send messages to other server classes 2.For each message that is generated, determine the collaborating class and the corresponding method in the server object 3.For each method in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits 4.For each of the messages, determine the next level of methods that are invoked and incorporate these into the test sequence

Behavioural Integration Testing lDerive tests from the object-behavioural analysis model lEach state in a State diagram should be visited in a “breadth-first” fashion.  Each test case should exercise a single transition  When a new transition is being tested only previously tested transitions are used  Each test case is designed around causing a specific transition lExample:  A credit card can move between undefined, defined, submitted and approved states  The first test case must test the transition out of the start state undefined and not any of the other later transitions

[3] Validation Testing lAre we building the right product? Validation succeeds when software functions in a manner that can be reasonably expected by the customer. lFocus on user-visible actions and user- recognizable outputs lDetails of class connections disappear at this level lApply:  Use-case scenarios from the software requirements spec  Black-box testing to create a deficiency list  Acceptance tests through alpha (at developer’s site) and beta (at customer’s site) testing with actual customers

[4] System Testing lSoftware may be part of a larger system. This often leads to “finger pointing” by other system dev teams lFinger pointing defence: 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 lTypes 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

Automated Testing lCPPUnit on SourceForge.net lDifferentiates between:  Errors (unanticipated problems usually caught by exceptions)  Failures (anticipated problems checked for with assertions) lBasic unit of testing:  CPPUNIT_ASSERT(Bool) examines an expression lCPPUnit has a variety of test classes (e.g. TestFixture). Approach is to inherit from them and overload particular methods

Testing Summary lTesting is integrated with and affects all stages of the Software Engineering lifecycle lStrategies: a bottom-up approach – class, integration, validation and system level testing lTechniques:  white box (look into technical internal details)  black box (view the external behaviour)  debugging (a systematic cause elimination approach is best) analysis designcodetest