Executable documentation

1
Executable documentation

• setting-up the project around acceptance tests

Wojciech.Biela_at_exorigo.pl Krzysztof.Jelski_at_exorigo
.pl www.ExOrigo.pl
Agile Day 2008, Budapest
2
Agenda

• INTRO
• documentation
• acceptance tests
• DEMO
• tools for AT
• web based app
• rich client app
• SET UP
• infrastructure
• relationships

3

• INTRO

4

• Many people misread books about agility in SE

5

• Documentation
• its a good thing

6

• There is a world out there
• (beyond MS Word
• or CASE tools)

7

• What is the purpose of documentation?
• ?

8

• Communication in a non-transient form
• Ensuring good quality
• Unambiguity
• Help introduce new people to the project
• Knowledge transfer
• Analyse the problem, to think it through
• Have a point of reference
• Enable verification
• Do some marketing (internal and external)
• Feeling safe
• Planning
• A base for a legal agreement (a contract)

9

• What attributes does good documentation have (or
  should have)?
• ?

10

• Verifiable
• Fitting the target audience
• Unambiguous
• Up-to-date
• Brief
• Easy to maintain
• Accessible for everyone
• Well organised (dependencies)
• Adapted to the current context
• Complete

11

• Do MS Word, UML, demonstrate those attributes
  by design?

12

• Non-executable artifacts are
• by design not safe

13

• Kinds of acceptance tests

14

• Manual tests

15

• Record-playback tests

16

• Domain-driven tests
• (up-front, automated)

17

• via the GUI
• (WWW, RCP)

18

• via the controller
• (just below the GUI)

19

• via the model
• (integration?)

20

• best practice for GUI/controller
• - Model View Presenter
• recently Passive View
• (Martin Fowler)
• Humble Dialog Box
• (Michael Feathers)
• - Presenter First (Agile 2006)

21

• Why?
• Regression

22

• Why?
• Know when to stop

23

• Why?
• We should deliver by features
• Mary Poppendieck

24

• Why?
• Prove it works

25

• Why?
• Prove it doesnt work

26

• Acceptance tests are NOT
• unit tests
• integration tests
• system tests
• performance tests

27

• Acceptance tests serve as
• a medium for the communication with the client

28

• They make sense only if you run them (often)

29

• Hey!
• But not everything is testable
• so what? cest la vie

30

• Not everything must be automated
• (be pragmatic)

31

• DEMO

32

• AT Tools
• Internet applications
• Selenium, Canoo Webtest,

33

• AT Tools
• Rich-client apps
• Fit / FitNesse, NUnitForms, Abbot, jfcunit, Jemmy

34

• AT Tools
• Combining tools

35

• EXAMPLE 1
• - Rich client
• Real world B2B app (reimplemented)
• Java (Swing)
• FitNesse (tool)
• Presenter First (technique)

36

• EXAMPLE 2
• Web app
• Java (Spring MVC)
• Real world B2B app (as is)
• FitNesse Selenium (tools)

37

• EXAMPLE 3
• Rich client
• Sample (proof of concept)
• C (.NET)
• FitNesse NUnitForms

38

• SET IT UP

39

• Continuous Integration environment
• CruiseControl, Luntbuild, ...

40

• Setting the project up
• doesnt mean tools
• and infrastructure

41

• Requirements specification oriented towards
  acceptance criteria
• Helps to focus

42

• Domain Specific Language
• per project
• per client

43

• Documentation

44

• Customer relationship
• based on AT

45

• Contracts
• (fixed time/scope)
• Use AT as
• specs
• acceptance criteria

46

• Thank you!
• Wojciech.Biela_at_exorigo.pl
• Krzysztof.Jelski_at_exorigo.pl
• www.ExOrigo.pl

47

• Write acceptance tests because ?

48

• Boss, we need to spend additional 30 on testing
  because ?

49

• Tests?
• Oh yeah, sure, if we have some spare time then
  well be delighted to do it

50

• Tests?
• Oh yeah, sure, we will be testing

51

• There are two kinds of teams (organisation),
  those who
• are testing
• will be testing

52

• Clients never say no
• to having tests

53

• The client quickly gets used to having
  acceptance tests and using them

54

• Clients can be persuaded to spending more for
  test automation