Techniques for Improving TestDriven Design Martin Wirsing LMU

  • Slides: 17
Download presentation
Techniques for Improving Test-Driven Design Martin Wirsing LMU München in cooperation with Hubert Baumeister

Techniques for Improving Test-Driven Design Martin Wirsing LMU München in cooperation with Hubert Baumeister and Alexander Knapp Monterey Workshop, Chicago, September 2003

Test-Driven Design n Test scenarios act as (partial) specifications and drive the design of

Test-Driven Design n Test scenarios act as (partial) specifications and drive the design of programs n n Extreme Programming - test for program design Use cases serve as basis for test scenarios n n OOSE - informal use cases (Jacobson, early 90’ties) FOOSE - formalized use cases (W, Knapp, 97) M. Wirsing: Techniques for Improving Test-Driven Design

Property-Driven Design Improve on Test-Driven Design by Joint development of test / formal spec

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

Contents n Property-driven Development n n Development approach Case study: A Multi User Dungeon

Contents n Property-driven Development n n Development approach Case study: A Multi User Dungeon Game M. Wirsing: Techniques for Improving Test-Driven Design

Property-Driven Design: Construction & Validation Techniques Use Case detail test implements Scenario test assertions

Property-Driven Design: Construction & Validation Techniques Use Case detail test implements Scenario test assertions extract & generalize construct Model Instrumented Model Abstracted Model Property verify (model check) Iterated development guided by user stories/use cases M. Wirsing: Techniques for Improving Test-Driven Design

Case Study: Multi User Dungeon Game Distributed game played via mobile phones Provided by

Case Study: Multi User Dungeon Game Distributed game played via mobile phones Provided by phone company n n 3 1 0 4 6 2 Start Room 5 Special Room Game Rules n n 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. M. Wirsing: Techniques for Improving Test-Driven Design

Use Case Development Develop Use Cases for the MUD Game MUD move to room

Use Case Development Develop Use Cases for the MUD Game MUD move to room look other players Player trade personal object . . . M. Wirsing: Techniques for Improving Test-Driven Design

Scenario Development Develop Scenarios for trade Use Case p 1: Playe r p 2:

Scenario Development Develop Scenarios for trade Use Case p 1: Playe r p 2: Playe r has(mask) has(book) offer(mask) offer(book) close. Trade() cancel. Trade() assert has(book) success. Trade has(mask) successful trade M. Wirsing: Techniques for Improving Test-Driven Design has(mask) !success. Trade has(book) unsuccessful trade

Property Extraction Construct Class Diagram and Derive Invariants and Pre-/Post Conditions inv: has ->for.

Property Extraction Construct Class Diagram and Derive Invariants and Pre-/Post Conditions inv: has ->for. All(p. Obj | p. Obj. player = self ) <<mobile object>> Player move(Room) offer(Pers. Obj o, Player to) close. Trade() cancel. Trade(). . . inv: player != null implies player. has ->includes( self ) 0. . 1 1 1 last. Offer 0. . 1 post: to. last. Offer. object = o and to. last. Offer. player = self Last offer obtained from another player M. Wirsing: Techniques for Improving Test-Driven Design 0. . * has Offer <<mobile object>> Personal. Object object

Modelling n Property Extraction Construct State Diagrams and Define Properties Define State Diagrams for

Modelling n Property Extraction Construct State Diagrams and Define Properties Define State Diagrams for players and environment offer(o, to)/ p. _rec. Offer(o, this) _cancel. Trade()/ u. cancel. Trade() success. Trade=false waiting n Define safety and lifeness properties: _rec. Offer(o, from)/ u. offer(o, from) No Deadlock n Players agree on the outcome of a trade : p 1. waiting and p 2. waiting implies p 1. success. Trade = p 2. success. Trade n. . . n close. Trade()/ p. _close. Trade() success. Trade=true has. add(last. Offer. object) p. _del(last. Offer. object) received. Offer offer(o, from)/ p. _rec. Offer(o, from) M. Wirsing: Techniques for Improving Test-Driven Design _can u. ca succ _close. Trade()/ u. close. Trade() has. add(last. Offer. object) p. _del(last. Offer. object) cancel. Trade()/ p. _cancel. Trade() success. Trade=fal

& ationing d i l a r V cto Refa Validation I: All Tests

& ationing d i l a r V cto Refa Validation I: All Tests are Successful… p 1: Playe r p 2: Playe r has(mask) has(book) offer(mask) offer(book) close. Trade() assert Test has(book) success. Trade M. Wirsing: Techniques for Improving Test-Driven Design has(mask)

& ationing d i l a r V cto Refa n Validation II: Model

& ationing d i l a r V cto Refa n Validation II: Model Checking Construct homomorphic abstraction of state diagrams _cancel. Trade()/ u. cancel. Trade() success. Trade=false offer(o, to)/ p. _rec. Offer(o, this) waiting n Model checking gives: n No Deadlock, but we get. . . _rec. Offer(o, from)/ u. offer(o, from) a counterexample: Players may not agree on the outcome of a trade close. Trade()/ p. _close. Trade() success. Trade=true has. add(last. Offer. object) p. _del(last. Offer. object) _close. Trade()/ u. close. Trade() has. add(last. Offer. object) p. _del(last. Offer. object) cancel. Trade()/ p. _cancel. Trade( success. Trade=fa received. Offer M. Wirsing: Techniques for Improving Test-Driven Design _ca u. ca suc offer(o, from)/ p. _rec. Offer(o, from)

& ationing d i l a r V cto Refa Revising the Test and

& ationing d i l a r V cto Refa Revising the Test and Testing Without and With Assertions Add additional check for success. Trade n. Run test again n. Run test with assertions n p 1: Playe r p 2: Playe r has(mask) has(book) offer(mask) Assertion checking shows source of error in close. Trade offer(book) close. Trade() assert Test has(book) has(mask) success. Trade Error found by testing Additional test M. Wirsing: Techniques for Improving Test-Driven Design

& ationing d i l a r V cto Refa n Revise State Diagrams

& ationing d i l a r V cto Refa n Revise State Diagrams Correct the state diagrams offer(o, to)/ p. _rec. Offer(o, this) Error correction _cancel. Trade()/ u. cancel. Trade() success. Trade=false waiting n Validation yields: All tests successful! Model checking _rec. Offer(o, from)/ u. offer(o, from) successful! close. Trade()/ p. _close. Trade() success. Trade=true has. add(last. Offer. object) p. _del(last. Offer. object) received. Offer offer(o, from)/ p. _rec. Offer(o, from) M. Wirsing: Techniques for Improving Test-Driven Design _can u. ca succ _close. Trade()/ u. close. Trade() has. add(last. Offer. object) p. _del(last. Offer. object) success. Trade=true cancel. Trade()/ p. _cancel. Trade() success. Trade=fal

& ationing d i l a r V cto Refa Validation Results of the

& ationing d i l a r V cto Refa Validation Results of the MUD Game MUD move to room look other players Player trade personal object Sequence and Activity Diagrams for Mobility Sequence and Activity Diagrams Sequence and State Diagrams . . . Validation completed: All tests and checks successful! M. Wirsing: Techniques for Improving Test-Driven Design

Tool Support Use Case Scenario detail Test Scenario Editor (under develpt) test Testing with

Tool Support Use Case Scenario detail Test Scenario Editor (under develpt) test Testing with Fit. Nesse and JUnit Model Instrumented Model Abstracted Model Program test assertions Property verify (model check) Hugo model checking and simulation (using SPIN and UPPAAL) M. Wirsing: Techniques for Improving Test-Driven Design extract & generalize JML assertions

Summary and Challenges n Property-Driven Design n Joint development of formal properties and model

Summary and Challenges n Property-Driven Design n Joint development of formal properties and model n Tests n Formal specification n Joint validation and verification Executable models (based on state/activity diagrams) n Immediate feedback n Allows to experiment with the system Tests/Specs + Refactoring = "Soft"ware Challenges n n n Integrating interactive theorem proving Specification covering criteria Abstraction techniques M. Wirsing: Techniques for Improving Test-Driven Design