Designing for Testability

1
Designing for Testability

• Eric Allen
• Rice University

2
Dont say this code isnt testable

• Design code so that it is testable
• When code seems impossible to test, it is a
  tremendous opportunity to re-evaluate the design
• of the application, and the programming language.

3
Keep Model Code Out of the View

• Code in the view interacts with Swing components
• Swing components are slow
• Swing components must be made invisible in tests
  (otherwise, remote testing may break, etc.)

4
Keep Model Code out of the View

• Testing graphical layouts is undesirable in
  general
• Minor graphical changes shouldnt break the tests
• The tests should pass despite the LAF

5
Leverage Static Type Checking

• Catch errors as early as possible
• vs.
• Keep the program running as long as possible

6
Leverage Static Type Checking

• Algebraic data Composite pattern vs. State
  pattern
• When cant we use the Composite pattern?
• When cant we use the State pattern?

7
Mediators and Collaborative Objects

• When several (stateful) objects collaborate to
  perform operations, test by creating a Mediator
  that refers to all collaborators
• Then a test case has a handle on all objects with
  a single reference

8
Mediators and Fault Lines

• Of course, virtually all objects in a program
  interact indirectly with all others
• Place Mediators along fault lines where
  interaction is dense
• Typically, fault lines correspond to packages/
  sets of packages

9
Mediators and Fault Lines

• Example
• MVC Architecture
• Each component (model, view, controller)
  corresponds to a fault line.
• Q. How does the controller help with
  testability?

10
Overload Methods with Complex Signatures

• For testing, you want to call methods with small
  signatures, but some method signatures are very
  large
• Overload methods small signatures, default
  values

11
Method Overloading

• Example
• class Scope
• public Entry lookup(Name n)
• overload with
• public Entry lookup(String s)
• lookup(Name.fromString(s))

12
Use Accessors that Dont Modify State

• Tests are like laboratory experiments
• Tests use accessors to check data
• If accessors modify state, there is no control

13
Specify Out-of-Program Components with Interfaces

• Isolate uncontrolled code as quickly as possible
• Implement interfaces with mock objects
• Mock objects behave stupidly just allow you to
  call against them

14
Use Recorders to Control State

• Recorders are mock object that record the
  sequence of calls made on them on a tape
• Extremely useful when testing multithreaded code
• Used extensively in DrJava

15
Write the Tests First!

• A great way to determine whether a design is
  testable is to first write the tests youd like
  to use
• A design that can pass the tests will necessarily
  be a testable design