1. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.1 OO Testing

2. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.2 OO and testing It is often said that OO reduces testing because of the reuse of inherited methods –This is not always true “The only really tangible benefit of object- oriented programming is that it allows you to change things easily” Martin Fowler, 1997

3. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.3 Object-oriented testing: Myth and Reality Robert V. Binder, Object Magazine, May 1995 www.rbsc.com/pages/myths.html

4. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.4 Perceptions about testing objects Testing by poking around becomes widespread and accepted practice: –The developer shows that objects do something useful without crashing –Someone else gets to try a few dirty tricks to break the software Impossible to say how much has been tested No test case design, –A powerful defect prevention strategy

5. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.5 Myth 1 Testing is unnecessary –Development is iterative so each class is tested by being reused in several builds –OO languages don’t allow as many mistakes as earlier languages Reality: Human error as likely as ever –Reuse does not guarantee coverage –“Trust but verify”

6. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.6 Myth 2 Testing gets in the way –Class development is exploratory, like telling a story; it flows and grows –Testing is destructive, rote; not a good use of developer talent Reality: A good testing strategy contributes

7. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.7 Myth 3 Testing is a structured / waterfall idea Reality: Testing can be incremental and iterative –“Design a little, code a little, test a little”

8. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.8 Myth 4 Testing of object-oriented software is trivial Reality: Hunches about testing coverage are notoriously optimistic –An abstract view of the software dynamics is necessary: control flow, data flow, state space –Little automation is available

9. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.9 Myth 5 Automated (scripted) GUI testing is sufficient Reality: Coverage is uncertain –The approach is of little use for embedded systems

10. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.10 Myth 6 Programming errors can be avoided –They are simply an indication of bad work habits Reality: OO systems tend to have more components and more interfaces –Interface errors surface only at integration

11. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.11 Myth 7 Testing OO software is the same as for “conventional” software –All we need is black-box testing, which ignores the internal structure Reality: Structure matters. –Inheritance, polymorphism, etc., create opportunities for new kinds of errors

12. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.12 Myth 8 Conventional testing is useless for objects –Control flow testing is meaningless since methods are small Reality: Conventional techniques can be adapted

13. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.13 Myth 9 By extending known foundation classes, you eliminate errors Reality: Each subclass is a different context for inherited features –Methods must be retested in their new contexts –(See Schach)

14. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.14 OO Testing Stephen R. Schach Software Engineering Chapter 12

15. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.15 General A method, m( ), often changes the state of the object – O – that it is invoked on. To see if m( ) generates the correct result, you must often call another method, O.n( ), that returns the appropriate part of the state. –Example: The methods deposit( ) and getBalance( ) on an object of class Account For testability, each class should have all the necessary “getter” methods.

16. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.16 Testing inherited methods An inherited method, once tested in the parent class, may need to be retested in the new environment of a child class Example: Tree hierarchy

17. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.17 class Rooted_Tree { … void display_node_contents(Node a); // display_node( ) uses print( ) void print (Node b);} class Binary_Tree: public Rooted_Tree { … void display( ); // Overriding method; uses print( )} class Balanced_B_Tree: public Binary_Tree { … void print(Node b); // Overriding method; used by inherited display( )}

18. 11/09/02(c) 2002 Bo Sanden, Colorado Tech.18 display( ) has been tested when operating on a Binary_Tree object It must be retested on a Balanced_B_Tree object since it now calls a different print( ) method