1 / 18

Testing Object-Oriented Programs

Testing Object-Oriented Programs. CS 4311 J. McGregor and D. Sykes. A Practical Guide to Testing Object-Oriented Software, Addison-Wesley , 2001. I. Burnstein. Practical Software Testing , Springer-Verlag, 2003. Outline. OO testing, why different? Class as unit Test harness

yadid
Download Presentation

Testing Object-Oriented Programs

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. Testing Object-Oriented Programs CS 4311 J. McGregor and D. Sykes. A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001. I. Burnstein. Practical Software Testing, Springer-Verlag, 2003.

  2. Outline • OO testing, why different? • Class as unit • Test harness • Testing class hierarchies

  3. What’s Different about Testing OO Programs? • Encapsulation • Polymorphism • Inheritance • Development

  4. Unit Testing OO Programs • Definition • A unit is the smallest possible testable software component, e.g., function, procedure, or module. • What’s unit in OO? • Method vs. class

  5. Method As Unit • Methods tend to be small and less meaningful in isolation • Impossible to test some methods (e.g., private methods) • Overhead to test each method separately

  6. Class As Unit • Purpose • Test a class as a whole • Emphasizes interactions among methods • Approach • Test critical methods individually • Test interactions among methods • Test sequences of methods calls, e.g., pop after push

  7. Testing Interactions • Why test interactions? • An OOP is a collection of objects collaborating to solve some problem. • The correct collaboration (or interaction) is critical to the correctness of the program. • Intra-class interactions • E.g., pop after push • Inter-class interactions (integration test) • Test sequences of messages among collaborating objects. • Can use interaction diagrams (e.g., message sequence diagrams and communication diagrams) and use case scenarios to generate test cases.

  8. Describing Test Cases Conventional definition A pair of inputs and the expected output, xi, o In OO Need to specify the receiver (often called object under test) and its state too, e.g., r in r.m(x1, x2, …, xn) Thus, it is a tuple of rpre, xi’s, rpost, o, e, where r : is the object under test rpre : the receiver r’s state in the pre-state xi’s : the arguments rpost : the receiver r’s state in the post-state o: expected return value e: expected exception

  9. Input Output receiver (r) args (x) receiver (r) return-value exception r.x = 10 x = 20 r.x = 20 none none r.y = 10 r.y = 10 Example • A test case for testing the method “void setX(int)” of the class Point with the instance fields x and y, e.g., Point r = new Point(10,10); r.setX(20);

  10. Constructing Test Cases • Testing individual methods • Black-box test and white-box test • Testing interactions • Random testing • State-based approach • Can use state machine diagrams to generate sequences of method calls • Testing exceptions • Design-by-Contract (DBC) vs. defensive design

  11. Outline • OO testing, why different? • Class as unit • Test harness • Testing class hierarchies

  12. unit under test stub1 driver stubn Test Harness • A test harness is the auxiliary code developed to support testing of units and components, consisting of: • Drivers that call the target code, and • Stubs that represents modules it calls. call result ack call call ack

  13. Constructing Test Harness • Conditionally compiled • Test code closely maintained with class code (e.g., in the same file) • Hard to reuse (e.g., to test a subclass) • Requires support for conditional compilation • As static methods or nested classes • Test code closely maintained with class code • Easy to reuse (e.g., by inheritance) • Need to strip down test code before product delivery • As separate tester class

  14. Separate Test Class Strengths Easy to reuse (e.g., to test a subclass) Small and fast production code Weaknesses Need to create a new tester class Need to manage changes carefully May not be able to access all features of the class under test Guideline Use unit testing frameworks such as xUnit: JUnit, PHPUnit, CppUnit, NUnit (C#). Tester CTester C

  15. Outline • OO testing, why different? • Class as unit • Test harness • Testing class hierarchies

  16. D bar() C foo() bar() Testing Class Hierarchies • If a new class D is added, what methods need to be tested? • Need test bar() of D? • What about inherited methods, e.g., foo()? • Can use existing test cases of C? • What if D adds a new method?

  17. Organizing Testing Harness • Parallel architecture for class testing (PACT) • Use inheritance to organize test cases and test classes Tester C CTester D DTester

  18. Testing Abstract Classes • Can you test abstract classes? • Approaches

More Related