daimihenrik bærbak christensen1 testability tactics how to make software testable

DAIMI Henrik Bærbak Christensen 1

Testability Tactics

How to make software testable...


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?


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


Bass et al.

Testability Tactics:– means to enhance testability


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!


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


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

execute()

<<interface>>Event

execute()attackRating()defenceRating()

<<interface>>AttackEvent

GameLoop AttackTestCase

execute() { ar = attackRating(); ...}

assertEquals(45, e.attackRating());


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


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

daimihenrik bærbak christensen1 testability tactics how to make software testable

Documents