1 / 18

OO Testing

OO Testing. 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.

rudolf
Télécharger la présentation

OO 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. OO Testing (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 (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 (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 (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” (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 (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” (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 (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 (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 (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 (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 (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) (c) 2002 Bo Sanden, Colorado Tech.

  14. OO Testing Stephen R. Schach Software Engineering Chapter 12 (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. (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 (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( )} (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 (c) 2002 Bo Sanden, Colorado Tech.

More Related