Class Testing Software Engineering of Standalone Programs University of Colorado, Boulder

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 2 Overview Class Testing Testing Interactions between objects Testing Class Hierarchies

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 3 Basics – How to test a single class Class Testing How to Test a Class Aspects of Class Testing How to Construct Test Cases When is a class test suite adequate? How to Construct a Test Driver Testing Interactions between objects Testing Class Hierarchies

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 4 Definition of class testing Verifying implementation of a class = verifying the specification for that class If so, each of the instances should behave properly. Assumption: The class in question has a complete and correct specification that has been tested earlier in the context of models Spec is expressed in natural language or as a state transition diagram

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 5 Ways to test a class Code can be tested effectively by inspection (preferable when construction of a test driver is too difficult) execution of test cases (lends itself to easy regression testing later on) Remember: When you test a class, you are really: creating instances of that class and testing the behavior of those instances.

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 6 Aspects of Class Testing Decide test independently test as a component of a larger part of the system How decide – combination of the following: Role of the class in the system – degree of risk Complexity of the class Amount of effort associated with developing a test driver Sometimes, needs so many collaborators, makes more sense to test in a cluster

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 7 Who Tests? How much? Who – class usually tested by its developer Understands class’ spec Familiar with the code Test driver can be used by the developer to debug code while writing it but... perpetuates misunderstanding – needs inspection at model stage to head that off What – ensure that the code for a class exactly meets the requirements – no more, no less

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 8 When are tests written? When – A test plan that identifies test cases should be developed soon after a class is fully specified and ready for coding. Especially if developer is the class tester Why? (What’s the danger in developer alone writing and reviewing test cases for the class?) When again? Iterative development – the driver and the test cases will be available to supplement or change as the class is enhanced or modified

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 9 How can you test “just a class”? How – Create a test driver that creates instances of the class sets up a suitable environment around those instances to run a test case sends one or more messages to an instance as specified by a test case checks the outcome based on a reply value, changes to the instance, or parameters to the message deletes any instances it creates if responsible for storage allocation

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 10 How do we test static data in a class? How – continued: Static data members or operations testing required they belong to the class itself rather than to each instance of the class the class can be treated as an object If the behavior of the instances of a class is based on the values of class-level attributes test cases for testing the class-level attributes must be considered as an extension of the state of the instances

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 11 How MUCH testing is done at this level? How much – Adequacy of testing measured in terms of how much of the specification has been tested how much of the implementation has been tested Want to test operations and state transitions in many combinations Objects maintain state. “State” affects the meaning of operations.

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 12 Constructing test cases - identification Identification of test cases Should be made from the specification that has been reviewed rather than from the implementation which may embody developer’s misunderstandings Best: develop from spec and augment to test boundaries introduced by the implementation If no spec exists: create one from the code and verify it with the developer

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 13 Constructing test cases – identification 2 Identify requirements for test cases for all possible combinations of situations in which a precondition can hold post conditions can be achieved Create test cases for those requirements specific input values – typical and boundary determine correct outputs eliminate conditions that are not meaningful Add test cases to show what happens when a precondition is violated

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 14 Constructing Test Cases – from STD’s State Transition Diagrams They show behavior associated with instances of a class Each transition represents a requirement for one or more test cases

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 15 Constructing test cases from STD’s 2 Suppose 6 transitions between states Plus 1 constructor and 2 destructors That makes 9 requirements Select representative values Select boundary values on each side of a transition If the transition is guarded, select boundary values for the guard condition Boundary values are based on the range of attribute values associated with a state

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 16 Top-level Statechart for Elevator Control

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 17 Adequacy of a Class Test Suite Ideally – exhaustively test each class Practically – impossible or too hard Worth it to exhaustively test some classes with high risk Measures of adequacy to increase confidence that we have tested enough state-based coverage constraint-based coverage Constraints are pre and post conditions and the class invariant code-based coverage

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 18 State-based coverage How many of the transitions in a state transition diagram are covered by the test suite? “Covered” = touched at least once May reveal each transition was covered but test values do not adequately cover value ranges If test cases were generated correctly from a state transition diagram with typical values and good boundary values, the test cases will achieve adequate state-based coverage If test cases were generated from pre- and post conditions, then it is useful to check them against the state transition diagram to ensure each transition is covered.

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 19 State-based coverage: object interaction Note how operations interact w.r.t. transitions Current State Input or event ActionOutputNext State SaE1O1Sc SbE2O2Sc E3Sd Test cases for the transition from Sc to Sd may work if Sc was reached from Sa but not if Sc was reached from Sb. “State” is a function of history.

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 20 State-based coverage: transition pairs Concerning problem on previous page: Check that the test cases cover all pairs of transitions in the state transition diagram. In previous table, create test cases to test: SaSc and ScSd SbSc and ScSd

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 21 Statechart for Elevator Control

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 22 Hierarchical statechart for Elevator Control

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 23 Portion enlarged

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 24 Constraint-based coverage How many pairs of pre- and post conditions have been covered? Using the technique described earlier for generating test cases from pre and post conditions, if one test case is generated to satisfy each requirement, then the test suite meets this measure

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 25 Constraint-Based coverage: object interaction For each operation opn that is not an accessor operation, identify the operations op1, op2, etc. for which their preconditions are met when the post conditions for opn hold. That is, post condition(opn) satisfies (>=) precondition(op1), etc. Then execute test cases for operation sequences opn-op1, opn-op2, etc.

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 26 Class Diagram ElevatorElevator Doors Timer Elevator Button Up Floor Button Floor m 0…n Travels-to Travels-from Opens- Closes Controls Contains velocity: ±m/s position: meters floor: integer on: Boolean open: Boolean closed: Boolean jammed: Boolean time: seconds floor: integer position: meters on: Boolean Down Floor Button 1 1 Contains on: Boolean Light 1 on: Boolean 1 Turns-on Elevator Controller 1 0…n Controls Requests-elevator-of Indicates-arrival-to

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 27 How do we complete the class test? States do not correspond 1-1 to methods or to classes so the state transition diagram gives a different perspective We want to adequately test the class Test each state transition, better yet, the pairs Look at the class diagram and see which classes send messages to it To create a driver to simulate each class sending msgs to the class-under-test could be difficult If you only test each association in this application, it may be a weak level of testing for that class

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 28 Constraint coverage completes testing it If you test class A calling every msg it can in class B, that’s more coverage but … If you use existing classes to do that, it’s hard to get the right combination set up to make it happen Alternative: Write a driver with sequences of messages to access sequences of methods in the class you are testing.

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 29 Which sequences?? Look at the post conditions of each method in the class you want to test Look at preconditions of each Find sequences where the Post(m1) >= pre(m2) the Post(m2) >= pre(m3) Send msgs to m1; m2; m3 Do this for all possible combinations

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 30 Completion check See which associations were tested by comparing to the class diagram See which state transitions were covered this way If some state transitions were missed or if some post/pre condition pairs or associations were missed, add a few tests

November 21, 2005 ECEN5543CSCI5548 Univ of Colorado -- Class Testing 31 Where do the pre and post conditions come from? Use cases?? The methods themselves? The class invariant?