1 / 31

Class Testing

Class Testing. Software Engineering of Standalone Programs University of Colorado, Boulder. Overview. Class Testing Testing Interactions between objects Testing Class Hierarchies. Basics – How to test a single class. Class Testing How to Test a Class Aspects of Class Testing

giza
Download Presentation

Class Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Overview • Class Testing • Testing Interactions between objects • Testing Class Hierarchies 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 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 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. 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 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 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 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 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 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. 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 ECEN5543CSCI5548 Univ of Colorado -- Class Testing

  13. Constructing test cases – identification2 • 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 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 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 ECEN5543CSCI5548 Univ of Colorado -- Class Testing

  16. Top-level Statechart for Elevator Control 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 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. ECEN5543CSCI5548 Univ of Colorado -- Class Testing

  19. State-based coverage: object interaction • Note how operations interact w.r.t. transitions 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. 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 ECEN5543CSCI5548 Univ of Colorado -- Class Testing

  21. Statechart for Elevator Control ECEN5543CSCI5548 Univ of Colorado -- Class Testing

  22. Hierarchical statechart for Elevator Control ECEN5543CSCI5548 Univ of Colorado -- Class Testing

  23. Portion enlarged 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 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. ECEN5543CSCI5548 Univ of Colorado -- Class Testing

  26. Elevator Controller Requests-elevator-of Controls 1 Indicates-arrival-to 0…n Elevator Opens-Closes Elevator Doors Timer Controls time: seconds velocity: ±m/s position: meters 1 1 1 1 open: Boolean closed: Boolean jammed: Boolean 1 0…n Travels-to 0…n Travels-from Controls m 1 1 Elevator Button Up Floor Button Floor Contains floor: integer position: meters 1 1 on: Boolean floor: integer on: Boolean 1 1 Turns-on Turns-on 1 1 1 Light Down Floor Button Turns-on Contains 1 1 on: Boolean 1 on: Boolean Class Diagram 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 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. 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 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 ECEN5543CSCI5548 Univ of Colorado -- Class Testing

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

More Related