Techniques for Improving TestDriven Design

1
Techniques for Improving Test-Driven Design

• Martin Wirsing
• LMU München

in cooperation with Hubert Baumeister and
Alexander Knapp
2
Test-Driven Design

• Test scenarios act as (partial) specifications
  and drive the design of programs
• Extreme Programming - test for program design
• Use cases serve as basis for test scenarios
• OOSE - informal use cases (Jacobson, early
  90ties)
• FOOSE - formalized use cases (W, Knapp, 97)

3
Property-Driven Design

• Improve on Test-Driven Design by
• Joint development of test / formal spec / model
• Executable models
• Immediate feedback
• Automatic tests
• Properties
• Basis for verification and improvement of testing
• Verification through model checking (and theorem
  proving)
• Refinement/Abstraction
• Adding/Deleting functionality and details
• Refactoring

4
Contents

• Property-driven Development
• Development approach
• Case study A Multi User Dungeon Game

5
Property-Driven Design Construction
Validation Techniques
Scenario
Use Case
Model
Property
Iterated development guided by user stories/use
cases
6
Case Study Multi User Dungeon Game

• Distributed game played via mobile phones
• Provided by phone company

3
1
0
6
4
2
5
Start Room
Special Room

• Game Rules
• The player moves through the rooms until he finds
  the Special Room.
• He can see the other players, trade objects, talk
  and fight with other players in the same room.

7
Develop Use Cases for the MUD Game
Use Case Development
MUD
move to room
8
Develop Scenarios for trade Use Case
Scenario Development
successful trade
unsuccessful trade
9
Construct Class Diagram and Derive Invariants
and Pre-/Post Conditions
Property Extraction
ltltmobile objectgtgt
0..
0..1
ltltmobile objectgtgt
PersonalObject
has
Player
move(Room) offer(PersObj o, Player
to) closeTrade() cancelTrade() . . .
object
1
1
lastOffer
0..1
0..1
Offer
10
Construct State Diagrams and Define
Properties
Modelling
Property Extraction
offer(o,to)/ p._recOffer(o,this)

• Define State Diagrams
• for players and
• environment

_cancelTrade()/ u.cancelTrade() successTradefalse
_cancelTrade()/ u.cancelTrade() successTradefalse

• Define safety and lifeness
• properties
• No Deadlock
• Players agree on
• the outcome of a trade
• p1.waiting and p2.waiting implies
• p1.successTrade p2.successTrade
• . . .

_recOffer(o,from)/ u.offer(o,from)
closeTrade()/ p._closeTrade() successTradetrue ha
s.add(lastOffer.object) p._del(lastOffer.object)
_closeTrade()/ u.closeTrade() has.add(lastOffer.ob
ject) p._del(lastOffer.object)
cancelTrade()/ p._cancelTrade() successTradefalse
offer(o,from)/ p._recOffer(o,from)
11
Validation I All Tests are Successful
12
Validation II Model Checking

• Construct
• homomorphic
• abstraction of
• state diagrams

_cancelTrade()/ u.cancelTrade() successTradefalse
offer(o,to)/ p._recOffer(o,this)
_cancelTrade()/ u.cancelTrade() successTradefalse

• Model checking gives
• No Deadlock,
• but we get ...

_closeTrade()/ u.closeTrade() has.add(lastOffer.ob
ject) p._del(lastOffer.object)
closeTrade()/ p._closeTrade() successTradetrue ha
s.add(lastOffer.object) p._del(lastOffer.object)
_recOffer(o,from)/ u.offer(o,from)
cancelTrade()/ p._cancelTrade() successTradefalse
offer(o,from)/ p._recOffer(o,from)
13
Revising the Test and Testing Without and With
Assertions

• Add additional
• check for
• successTrade
• Run test again
• Run test with
• assertions

has(book)
has(mask)
successTrade
successTrade
Additional test
14
Revise State Diagrams
Error correction
offer(o,to)/ p._recOffer(o,this)

• Correct the
• state diagrams

_cancelTrade()/ u.cancelTrade() successTradefalse
_cancelTrade()/ u.cancelTrade() successTradefalse

• Validation yields
• All tests successful!
• Model checking
• successful!

closeTrade()/ p._closeTrade() successTradetrue ha
s.add(lastOffer.object) p._del(lastOffer.object)
_closeTrade()/ u.closeTrade() has.add(lastOffer.ob
ject) p._del(lastOffer.object) successTradetrue
_recOffer(o,from)/ u.offer(o,from)
cancelTrade()/ p._cancelTrade() successTradefalse
offer(o,from)/ p._recOffer(o,from)
15
Validation Results of the MUD Game
MUD
Sequence and Activity Diagrams for Mobility
move to room
Sequence and Activity Diagrams
Sequence and State Diagrams
Validation completed All tests and checks
successful!
16
Tool Support
Scenario
Use Case
detail
Test Scenario Editor (under develpt)
test
Testing with FitNesse and JUnit
extract generalize
test assertions
Instrumented Model
Model
Property
Abstracted Model
verify (model check)
JML assertions
Hugo model checking and simulation (using SPIN
and UPPAAL)
Program
17
Summary and Challenges

• Property-Driven Design
• Joint development of formal properties and model
• Tests
• Formal specification
• Joint validation and verification
• Executable models (based on state/activity
  diagrams)
• Immediate feedback
• Allows to experiment with the system
• Tests/Specs Refactoring "Soft"ware

• Challenges
• Integrating interactive theorem proving
• Specification covering criteria
• Abstraction techniques