1. Object-oriented Testing SIM3302

2. Objectives To cover the strategies and tools associated with object oriented testing  Analysis and Design Testing  Class Tests  Integration Tests  Validation Tests  System Tests

3. Object-oriented Testing When should testing begin? Analysis and Design:  Testing begins by evaluating the OOA and OOD models  How do we test OOA models (requirements and use cases)?  How do we test OOD models (class and sequence diagrams)?  Structured walk-throughs, prototypes  Formal reviews of correctness, completeness and consistency Programming:  How does OO make testing different from procedural programming?  Concept of a ‘unit’ broadens due to class encapsulation  Integration focuses on classes and their context of a use case scenario or their execution across a thread  Validation may still use conventional black box methods

4. Testing Analysis and Design Syntactic correctness:  Are UML and ADT notation used correctly? Semantic correctness:  Does the model reflect the real world problem?  Is UML used as intended by its designers?  Is the ADT design complete (capturing all the classes and operations in UML diagram) and understandable? Testing for consistency:  An inconsistent model has representations in one part that are not reflected in other portions of the model

5. Testing the Class Model 1. Revisit the Use Cases, CRC cards and UML class model. Check that all collaborations are properly represented. Inspect the description of each CRC index card to make sure 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 2. Invert connections to ensure that each collaborator asked for a service is receiving requests from a reasonable source Example: a credit card being asked for a purchase amount Have you tested your analysis and design? If not, who will do it?

6. Testing OO Code Class tests Systemtests Integrationtests Validationtests

7. Object-oriented Testing Strategies(1) Unit Testing  Smallest testable unit is the encapsulated class or object  Test each operation as part of a class hierarchy because its class hierarchy defines its context of use  Driven by class operations and state behavior, not algorithmic detail and data flow across module interface  Approach: Test each method (and constructor) within a class Test the state behavior (attributes) of the class between methods  Complete test coverage of a class involves Testing all operations Setting and interrogating all object attributes Exercising the object in all possible state  Test sequences are designed to ensure that relevant operations are exercised  State of the class is examined to determine if errors exist

8. Object-oriented Testing Strategies(2) Unit Testing …  How is class testing different from conventional testing?  Conventional testing focuses on input- process-output, whereas class testing focuses on each method, then designing sequences of methods to exercise states of a class  But white-box testing can still be applied

9. Object-oriented Testing Strategies(3) Integration Testing  OO does not have a hierarchical control structure so conventional top- down and bottom-up integration tests have little meaning  Focuses on groups of classes that collaborate in some manner  Integration of operations one at a time into a class is often meaningless Because of direct and indirect interaction of components  Thread-based testing Testing/integrate the set of classes required to respond to one input or event  Use-based testing (integrates classes required by one use cas Begins by testing independent classes that use very few of server classes Next layer of classes (dependent classes) that use the independent classes are tested next  Cluster testing Groups of collaborating classes are tested for interaction errors  Regression testing is important as each thread, cluster or subsystem is added to the system

10. Object-oriented Testing Strategies(4) Validation Testing  Are we building the right product?  Validation succeeds when software functions in a manner that can be reasonably expected by the customer.  Focuses on visible user actions and user recognizable outputs  Validation tests are based on the use-case scenarios, the object behavior model, and the event flow diagram Apply:  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

11. Object-oriented Testing Strategies(5) Software may be part of a larger system. This often leads to “finger pointing” by other system dev teams Finger 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 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

12. Test Case Design(1) Each test case should be uniquely identified and be explicitly associated with a class to be tested the purpose of the test should be stated A list of testing steps should be developed for each test and contains:  A list of specified states for the object that is to be tested  A list of messages and operations that will be exercised as a consequence of the test  A list of exceptions that may occur as the object is tested  A list of external conditions needed to be changed for the test  Supplementary information required to understand or implement the test OO testing focuses on designing appropriate sequences of operations

13. Testing Methods at the Class Level(1) Random Testing : requires large number of data permutation and combination Identify operations applicable to a class Define constraints on their use– e.g. the class must always be initialized first Identify a minimum test sequence – an operation sequence that defines the minimum life history of the class Generate a variety of random test sequences– this exercises more complex class instance life histories

14. Testing Methods at the Class Level(2) Example of Random Testing 1) consider an account class that has the following operations: open, setup, deposit, withdrawal, balance, summarize, credit Limit, close 2) The account must be opened first and closed on completion

15. Testing Methods at the Class Level(3) Example of Random Testing 3) a variety of behaviors may occur: open setup deposit [deposit | withdrawal | balance| summarize | credit limit] n withdrawal close 4) different operation sequences can be generated randomly: test case #1: open setup deposit deposit balance summarize withdrawal close test case #2: open setup deposit withdrawal deposit balance credit limit withdrawal close

16. Testing Methods at the Class Level(4) Partition Testing : reduces the number of test cases required to test a class (remember ECP) Input and output are categorized Deriving partitioning categories:  State-based partitioning Categorizes class operations based on their ability to change the state of the class Tests designed in way so that operations that cause state changes are tested separately from those that do not Example: Test case #sp1: open setup deposit deposit withdrawal withdrawal close Test case #sp2: open setup depositsummarize credit limit withdrawal close

17. Testing Methods at the Class Level(5) Deriving partitioning categories:  Attribute-based partitioning Categorizes class operations based on the attributes that they use and modify Tests designed in way so that operations that use or modify attributes are tested separately from those that do not use or modify attributes Example: for the account class, the attributes balance and credit limit can be used to define operations. Operations are divided into three partitions: 1) operations that use credit limit 2) operations that modify credit limit 3) operations that do not use of modify credit limit

18. Testing Methods at the Class Level(6) Deriving partitioning categories:  Category-based partitioning Categorizes class operations based on the generic function that each performs such as initialization, computation, query, termination Example: operations in the account class can be categorized as: 1) initialization (open, setup) 2) computation (deposit, withdraw) 3) queries (balance, summarize, credit limit) 4) termination (close)

19. Interclass Test Case Design(1) Test case design becomes more complicated as integration of the OO system begins – testing of collaboration between classes Refer to diagram

20. Interclass Test Case Design(2) Multiple class testing  For each client class, use the list of class operators to generate a series of random test sequences that send messages to other server classes  For each message generated, determine the collaborator class and the corresponding operator in the server object  For each operator in the server object (invoked by a client object message), determine the message that it transmits  For each of the message, determine the next level of operators that are invoked and incorporate these into the test sequence.

21. Interclass Test Case Design(3) Multiple class testing : example Consider a sequence of operations for the bank class relative to an ATM class: verifyAcct verifyPin [[verifyPolicy withdrawReq] | depositReq | AcctInfoReq] n A random test case for the bank class might be Test case #r3: verifyAcct verifyPin depositReq The collaborators invoked for the above test case are ValidationInfo to execute verifyAcct and verifyPin. Collaborate with Account to execute depositReq Thus a new test case is Test case #r4 : verifyAcct Bank [validAcct ValidationInfo ] verifyPin Bank [ValidPin ValidationInfo depositR eq [deposit Account ]

22. Interclass Test Case Design(4) Test derived from behavior models  Use the state transition diagram as a model  Test cases must cover all states  Breadth first traversal of the state model can be used (test one transition at a time and only make use of previously tested transitions when testing a new transition

23. Testing Methods Applicable at Interclass Level(1) Cluster Testing  Concerned with integrating and testing clusters of cooperating objects  Identify clusters using knowledge of the operation of objects and the system features that are implemented by these clusters  Approaches to cluster testing Use-case or scenario testing  Testing is based on a user interactions with the system  Has the advantage that it tests systems features as experienced by users Thread testing – tests the systems response to events as processing threads through the system Object interaction testing – test sequences of object interactions that stop when an object operation does not call on services from another object

24. Testing Methods Applicable at Interclass Level(2) Use Case/Scenario-based Testing  Based on Use cases Corresponding sequence diagrams  Identify scenarios from use-case and supplement these with interaction diagrams that show the objects involved in the scenario  Concentrates on functional requirements Every use case Every fully expanded ( >) combination Tests normal as well as exceptional behavior

25. OO Test Design Issues White-box testing methods can be applied to testing the code used to implement operations Black-box testing methods are appropriate for testing OO systems OO programming brings additional testing concerns  Classes may contain operations that are inherited from superclass  Subclasses may contain operations that were redefined rather than inherited  All classes derived from a previously tested base class need to be thoroughly tested.

26. Summary One strategy is a bottom-up approach – class, integration, validation and system level testing