1. DAIMIHenrik Bærbak Christensen1 Testability Tactics How to make software testable...

2. DAIMIHenrik Bærbak Christensen2 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. DAIMIHenrik Bærbak Christensen3 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. DAIMIHenrik Bærbak Christensen4 Bass et al. Testability Tactics: –means to enhance testability

5. DAIMIHenrik Bærbak Christensen5 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. DAIMIHenrik Bærbak Christensen6 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. DAIMIHenrik Bærbak Christensen7 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. DAIMIHenrik Bærbak Christensen8 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. DAIMIHenrik Bærbak Christensen9 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).