This document discusses design for testability. It defines testability as having controllability and visibility. Controllability is the ability to apply inputs and place a system in specified states, while visibility is the ability to observe states and outputs. The document outlines why testability is important for improving quality and reducing costs. It describes how to achieve testability through good design practices like abstraction, encapsulation, and avoiding interdependence. Testability features like logging and assertions are also recommended. Development techniques like defensive programming, design by contract, and test-driven development can further enhance testability.

1. R&D Dept.
Switching Division
Testing Team
Design for Testability
Prepared By:
-
Amr Medhat
-
13 - 4 - 2006
-

2. Outline
 Testability: what, why, how and when?
 The Design Dilemma
 Testability Features
 Techniques for Developing Quality-
Oriented Software
Design for Testability

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. 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. Testability .. How?
 Investing more time in design
[A good design is a testable design]
 Adding testability features
 Using special techniques throughout
the development process
Design for Testability

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 requirements
Design for Testability

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. 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. 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  Polymorphism
Design for Testability

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. 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 Relation
Design for Testability

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 classes
Design for Testability

13. Copy
Reader Writer
Keyboard Printer Disk
Reader Writer Writer
Read Write Write
Keyboard Printer Disk
OCP Example
Printer
Write
Design for Testability
Write
Copy
Disk
Keyboard
Read

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. Testability Features
 Logging events & verbose mode
support
 Assertions {make assumptions explicit}
 Test points (fault injection hooks)
 Scriptable installation process
Design for Testability

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 warning
Design for Testability

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 stubs
Design for Testability

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. 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 code
Design for Testability

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 development
Design for Testability

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+Standards
Design for Testability

22. R&D Dept.
Switching Division
Testing Team
Thank You Very Much