R&D Dept.Switching DivisionTesting Team      Design for Testability            Prepared By:                               ...
Outline     Testability: what, why, how and when?     The Design Dilemma     Testability Features     Techniques for D...
Testability .. What?     Testability = controllability & visibility           Controllability: the ability to apply inpu...
Testability .. Why?     Improve software quality     Ease the test process and more support      for test automation   ...
Testability .. How?         Investing more time in design          [A good design is a testable design]         Adding...
Testability .. When?                          From Day 1      Testers has to be engaged early in the      product devel...
The Design Dilemma           The time given for design.... ?!           Using the perfect tools....                    ...
Design Weakness: How &        Why     Symptoms of a bad design           Rigidity           Fragility           Immobi...
Abstraction & Interfaces     Separate interface from its implementation     use overriding to support polymorphism     ...
Encapsulation     Data are Private, Methods are Public…,      & Implementation Details are Hidden     Encapsulating the ...
Interdependence     The Acyclic Dependencies Principle      (ADP)         Dependencies must not form cycles     3 ways o...
Class Design Principles     The Single Responsibility Principle      (SRP) class has only one responsibility        Each ...
Copy               Reader           Writer              Keyboard          Printer         Disk               Reader       ...
LSP Example  class Bird {                                           class Penguin : public Bird {    public: virtual void ...
Testability Features     Logging events & verbose mode      support     Assertions {make assumptions explicit}     Test...
Testability Features (cont.)     Benefits of Adding Testability Features           Detecting internal errors before they...
Development Techniques         Defensive Programming        Assertions everywhere         Design by Contract         T...
Design by Contract     Preconditions        what must be true when a method is invoked     Postconditions        what ...
Test-Driven Development     Write tests first, then write the minimal code      the makes this test pass     Tests provi...
Summary     Design Better           Use interfaces           Don’t violate encapsulation           Avoid interdependen...
References  1.      Bret Pettichord, “Design for Testability”  2.      Jeffery E. Payne, Roger T. Alexander, Charles D. Hu...
R&D Dept.Switching DivisionTesting Team      Thank You Very Much
Upcoming SlideShare
Loading in …5
×

Software Design for Testability

5,942 views

Published on

  • Be the first to comment

Software Design for Testability

  1. 1. R&D Dept.Switching DivisionTesting Team Design for Testability Prepared By: - Amr Medhat - 13 - 4 - 2006 -
  2. 2. Outline  Testability: what, why, how and when?  The Design Dilemma  Testability Features  Techniques for Developing Quality- Oriented SoftwareDesign for Testability
  3. 3. Testability .. What?  Testability = controllability & visibility  Controllability: the ability to apply inputs to s/w under test & place it in specified states  Visibility: the ability to observe states and outputs [what we see is what we test]Design for Testability
  4. 4. Testability .. Why?  Improve software quality  Ease the test process and more support for test automation  Cost reduction The average software company spends 60-80% of its development costs on supporting [Lidor Wyssocky]Design for Testability
  5. 5. Testability .. How?  Investing more time in design [A good design is a testable design]  Adding testability features  Using special techniques throughout the development processDesign for Testability
  6. 6. Testability .. When?  From Day 1   Testers has to be engaged early in the product development cycle  The product has to be open for design changes to meet the testing requirementsDesign for Testability
  7. 7. The Design Dilemma  The time given for design.... ?!  Using the perfect tools.... But in the wrong way ... !!! ? modularity? Polymorphism scalability?Encapsulation reliability? reusability? Inheritance maintainability?Data Abstraction Design for Testability
  8. 8. Design Weakness: How & Why  Symptoms of a bad design  Rigidity  Fragility  Immobility  Viscosity  Causes of a bad design  Lack of Abstraction  Violation of Encapsulation  Interdependence {between Objects & Layers}Design for Testability
  9. 9. Abstraction & Interfaces  Separate interface from its implementation  use overriding to support polymorphism  When deriving a class, inherit interface not implementation  Implementation is either Extended  Or, Overridden  PolymorphismDesign for Testability
  10. 10. Encapsulation  Data are Private, Methods are Public…, & Implementation Details are Hidden  Encapsulating the data and the functions operating on this data. myThing[] things = thingManager.getThingList(); for (int i = 0; i < things.length; i++) { myThing thing = things[i];  if (thing.getName().equals(thingName)) { return thingManager.delete(thing); } } return thingManager.deleteThingNamed(thingName); Design for Testability
  11. 11. Interdependence  The Acyclic Dependencies Principle (ADP) Dependencies must not form cycles  3 ways of communication  Invoke Method  Superiority Relation  Raise Trigger  Inferiority Relation  Message Passing  Peer RelationDesign for Testability
  12. 12. Class Design Principles  The Single Responsibility Principle (SRP) class has only one responsibility Each  The Open-Closed Principle extension A module should be open for (OCP) but closed for modification  The Liskov Substitution Principle (LSP) Subclasses should be substitutable for their base classesDesign for Testability
  13. 13. Copy Reader Writer Keyboard Printer Disk Reader Writer Writer Read Write Write Keyboard Printer DiskOCP Example Printer Write Design for Testability Write Copy Disk Keyboard Read
  14. 14. LSP Example class Bird { class Penguin : public Bird { public: virtual void fly(); public: void fly() { }; error (“Penguins don’t fly!”); } }; class Parrot : public Bird { public: virtual void mimic(); }; void PlayWithBird (Bird& abird) { abird.fly(); // OK if Parrot. // if bird happens to be Penguin...OOOPS!! } Does not model: “Penguins can’t fly” It models “Penguins may fly, but if they try it is error” Run-time error if attempt to fly → not desirable Design for Testability
  15. 15. Testability Features  Logging events & verbose mode support  Assertions {make assumptions explicit}  Test points (fault injection hooks)  Scriptable installation processDesign for Testability
  16. 16. Testability Features (cont.)  Benefits of Adding Testability Features  Detecting internal errors before they propagate  Knowing the source and place of the problem easily  Ability to reproduce bugs many times  Notes  Time stamps may be useful in logging  Well describe and identifying the logged event  Agree on a standard format of logging all over the system [The use of a stand-alone Logger]  Use variable levels of logging  Throwing exceptions upon an assertions violation may be useful rather than just logging it as a warningDesign for Testability
  17. 17. Development Techniques  Defensive Programming Assertions everywhere  Design by Contract  Test-Driven Development  Mock Objects A generic unit testing framework that supports TDD better than test stubsDesign for Testability
  18. 18. Design by Contract  Preconditions what must be true when a method is invoked  Postconditions what must be true after a method completes successfully.  Class invariants what must be true about each instance of a class.Design for Testability
  19. 19. Test-Driven Development  Write tests first, then write the minimal code the makes this test pass  Tests provide the required specification for the developer {A part of the documentation}  Provides rapid feedback for the developer  Emphasizes fast, incremental development  Functionality is added in very small chunks  Ensures 100% thoroughly unit tested codeDesign for Testability
  20. 20. Summary  Design Better  Use interfaces  Don’t violate encapsulation  Avoid interdependence and cycles  Class single responsibility  Class open for extension closed for modification  Class substitution (parent is more general than its child)  Add Testability Features  Logging  Assertions  Fault injection hooks  Enhance the Development Process  Design by contract  Test-driven developmentDesign for Testability
  21. 21. References 1. Bret Pettichord, “Design for Testability” 2. Jeffery E. Payne, Roger T. Alexander, Charles D. Hutchinson, “Design-for-Testability for Object-Oriented Software” 3. Robert Martin, “OO Design Quality Metrics An Analysis of Dependencies” 4. Rahul Tyagi, “Two principles to help create robust, reusable object- oriented design apps” 5. Robert C. Martin, “Design Principles and Design Patterns” 6. Matt Weisfeld, "Object-Oriented Thought Process", Second Edition, Sams Publishing 7. Wikipedia 8. http://www.johndeacon.net/OOAandD/top25GoldenRules.asp 9. http://www.artima.com/weblogs/viewpost.jsp?thread=132358 10. http://labs.cs.utt.ro/labs/ip2/html 11. http://www.mertner.com/confluence/display/MbUnit/Design+StandardsDesign for Testability
  22. 22. R&D Dept.Switching DivisionTesting Team Thank You Very Much

×