Testability Tactics

1
Testability Tactics

• How to make software testable...

2
Motivation

• You must test that the move validation algorithm
  in a backgammon is reliable.
• validity v(board-state, move,player, die)
• You must test that meteorological reports are
  properly formatted based upon sensor readings
• how do you test fog condition on a clear day?
• You must test an complex RPG attack algorithm
• but it is based upon calculating 8 intermediate
  results that are encapsulated in the AttackEvent
  class...
• You must test a Chess AI
• only outputs the best move but did it find it
  the way we expect?

3
Bass et al.

• Testability
• ease with which the software can be made to
  demonstrate its faults
• A backgammon that hardcode the random function is
  not testable
• A meteorological system that hardcode sensors as
  data sources is not testable

4
Bass et al.

• Testability Tactics
• means to enhance testability

5
Tactics

• TestCase (input, expected output)
• Thus managing input/output becomes evidently
  important.
• Record/playback
• capture events flowing to a UUT for later
  playback
• example Macro recorders for GUI events allow
  testing graphical user interfaces (resulting
  output must also be recorded ?)
• record actual sensor readings from an airport
• important with realistic data.
• WarStory A graph plotting package that I made
  was tested with 0-100 range. But it should be
  used for laser measurements 1e-8 range. Bang!

6
Tactics

• Separate interface from implementation
• GoF 1st principle Program to an interface
• Make a random interface and supply concrete
  classes (Strategy Pattern)
• RandomDieStrategy Use random method
• JediDieStrategy Returns a value set by a
  setValue method
• Make a hardware encapsulating interface
• playback recorded data over that or again set
  values

7
Tactics

• Specialized access routes/interfaces
• The problem is to get hold of intermediate
  results or calculations.
• Solution 1 Expose them in public interface
• ? breaks encapsulation, production code clients
  are tempted to use them
• Tactic Expose them only in sub-interface that is
  not accessible from ordinary client code

8
Tactics

• Build-in Monitors
• Unit records and stores volatile state
  information
• like timings, capacity, security
• that can be inspected with special access
  interfaces
• Observer pattern is often great to inject testing
  code unobtrusively into production code
• public onConsiderChessMove(Move m)

9
Summary

• Production code is often not testable be default.
  Tactics propose some concrete techniques that
  make production code more testable.
• Often the design also improves by lowering
  coupling (program to an interface) and
  introducing variability points (patterns).