R&D Dept.

Switching Division Testing Team

Design for Testability

Prepared By:
-

Amr Medhat
13 - 4 - 2006 -

Outline

Testability: what, why, how and when? The Design Dilemma Testability Features Techniques for Developing QualityOriented Software

Design for Testability

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

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

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

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

The Design Dilemma

The time given for design.... ?!

Using the perfect tools.... But in the wrong way ... !!! ?
modularity? scalability? reliability? reusability? maintainability?

Polymorphism Encapsulation Inheritance Data Abstraction

Design for Testability

Design Weakness: How & Why

Symptoms of a bad design

Rigidity Fragility Immobility Viscosity Lack of Abstraction Violation of Encapsulation Interdependence {between Objects & Layers}

Causes of a bad design

Design for Testability

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

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

Interdependence

The Acyclic Dependencies Principle

Dependencies must not form cycles

(ADP)

3 ways of communication

Invoke Method Superiority Relation Raise Trigger Inferiority Relation Message Passing Peer Relation

Design for Testability

Class Design Principles

The Single Responsibility Principle (SRP)

Each class has only one responsibility

The Open-Closed Principle (OCP)

A module should be open for extension but closed for modification

The Liskov Substitution Principle (LSP)

Subclasses should be substitutable for their base classes

Design for Testability

OCP Example
Copy

Copy

Reader

Writer

Read Keyboard Write Disk

Design for Testability

Write Printer

Keyboard Reader

Printer Writer

Disk Writer

Read Keyboard

Write Printer

Write Disk

LSP Example
class Bird { public: virtual void fly(); }; class Parrot : public Bird { public: virtual void mimic(); };

class Penguin : public Bird { public: void fly() { error (Penguins dont fly!); } };

void PlayWithBird (Bird& abird) { abird.fly(); // OK if Parrot. // if bird happens to be Penguin...OOOPS!! }

Does not model: Penguins cant 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

Testability Features

Logging events & verbose mode support Assertions {make assumptions explicit} Test points (fault injection hooks) Scriptable installation process

Design for Testability

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 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

Notes

Design for Testability

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

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

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

Summary

Design Better

Add Testability Features

Use interfaces Dont 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)
Logging Assertions Fault injection hooks

Enhance the Development Process

Design by contract Test-driven development

Design for Testability

References
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
11.

Bret Pettichord, Design for Testability Jeffery E. Payne, Roger T. Alexander, Charles D. Hutchinson, Design-for-Testability for Object-Oriented Software Robert Martin, OO Design Quality Metrics An Analysis of Dependencies Rahul Tyagi, Two principles to help create robust, reusable objectoriented design apps Robert C. Martin, Design Principles and Design Patterns Matt Weisfeld, "Object-Oriented Thought Process", Second Edition, Sams Publishing Wikipedia http://www.johndeacon.net/OOAandD/top25GoldenRules.asp http://www.artima.com/weblogs/viewpost.jsp?thread=132358 http://labs.cs.utt.ro/labs/ip2/html

http://www.mertner.com/confluence/display/MbUnit/Design+Standards

Design for Testability

R&D Dept. Switching Division Testing Team

Thank You Very Much