St. Louis Code Camp

1
Fitnesse and .NET

• Achieving Customer Zen With Fitnesse

2
Overview

• The problem with customers
• Figuring out what customers want
• Executable Specifications
• How Fitnesse can help
• Fitnesse Demos
• Wrap-up

3
The Customer Problem

• If we dont take care of the customers, maybe
  theyll stop bugging us

4
The Customer Problem

• Customers arent developers
• Developers arent (usually) customers
• Customers dont know what they want until they
  see it

5
What Customers Want

• How do we show customers what they want?
• In a way they can understand
• In a way that elicits immediate feedback
• In a way that allows them to explore
• Without building entire system

6
What Customers Want

• Mock-Ups
• Screen grabs
• Sketches on paper or whiteboard
• Visio Diagrams
• Good for initial discussions
• Allows customer to explore in some fashion
• Hard to keep up with the latest state of the
  system

7
What Customers Want

• Prototyping
• Make a throw away version
• Allows customer interaction at a more concrete
  level
• More expensive than mock-ups
• Customers may not understand difference between
  prototype and real system
• May be hard to keep up with the real system

8
What Customers Want

• Frequent Releases
• Shows customer what is finished
• Shows customer the current state of the system
• Hard for customer to explore with
• Customer has to wait for release to play with new
  version
• Customer can only explore GUI elements

9
What Customers Want

• Need something between prototype and actual
  release
• Ties domain concepts to code
• Proves when feature is done in a repeatable
  fashion
• Customer-centric and developer friendly
• Ties as closely as possible to the real system

10
Executable Specifications

• A way of modeling specifications in a way that
  allows them to be executed to prove the system
  meets the spec
• Abstract State Model
• Any algorithm can be modeled at its natural
  abstraction level by an appropriate ASM
• By being able to run the model, you can validate
  the algorithm

11
Executable Specifications

• The appropriate abstraction level for business
  problems is usually a business (or domain)
  specific language
• By allowing the domain language to be executable,
  users get fast feedback
• Domain concepts can be translated directly into
  code

12
How Fitnesse Helps

• Which is clearer?
• This?

Testpublic void CreateRoomAddsRoomToRoomList()
Assert.AreEqual(0, chatApp.AvailableRooms.Coun
t) chatApp.CreateRoom(aRoom, aUser)
Assert.AreEqual(1, chatApp.AvailableRooms.Count)
Room room chatApp.AvailableRooms.GetRoomByName
(aRoom) Assert.AreEqual(1, room.UserCount)
Assert.IsTrue(room.Users.Contains(aUser))
13
How Fitnesse Helps

• Or this?

14
How Fitnesse Helps

• So what is this magical Fitnesse?
• Two pieces
• FIT (Framework for Integration Tests)
• Fitnesse
• Allows specifications to be written in HTML,
  Excel or Wiki format
• Can use any language underneath (runners for
  .NET, Java, Python, Ruby and others)

15
How Fitnesse Helps

• Fitnesse
• Uses Wiki format
• Allows collaborative efforts between customers
  and developers
• Is about communication first, testing second
• Easy to use syntax
• Straightforward to hook to the system being tested

16
How Fitnesse Helps

• Different Types of Tables
• ColumnFixture
• RowFixture
• DoFixture
• ActionFixture
• Custom Fixtures
• Many others

17
How Fitnesse Helps

• Helps solve 3 major problems
• Communication
• Agility
• Balance
• Side effect benefits
• Regression tests
• Domain concepts exposed

18
Chat Application Demo

• Chat Application
• Customer wants a simple chat application where
  users can create rooms and join existing ones
• Specifications are being captured into Fitnesse
  fixtures and hooked to the system under test

19
Chat Application Demo

• Specification Example

20
Chat Application Demo

• Customer found a hole in the specification by
  writing Fitnesse tests
• When the last user leaves, the room should be
  deleted

21
Chat Application Demo

• Because the domain concepts are translated into
  code, the developers can quickly write the
  corresponding unit test

22
Chat Application Demo

• And then get the unit test to pass by writing the
  code

23
Chat Application Demo

• And because Fitnesse ties into the system under
  test, we can see our change meets the
  specification immediately

24
Business Rules Demo

• The table based nature of Fitnesse is excellent
  for communicating Business Rules
• If you can capture the concepts in a table form,
  you can write it in Fitnesse

25
Business Rules Demo

• Business Holidays
• Different businesses have different days which
  they may count as holidays
• Interfacing with them may mean having to know
  what holiday applies to what business
• Sounds like a good Fitnesse test!

26
Business Rules Demo

• Fitnesse Test and Code

27
Business Rules Demo

• Shipping Charges
• Online store with shopping cart
• Shipping Charges are based on order amounts
• Customers get free shipping if they are over a
  set amount, or if they have preferred customer
  status

28
Business Rules Demo

• We want an initial user list we can reuse
  throughout our tests

29
Business Rules Demo

• Our other fixtures can now make use of our setup
  code

30
Wrap-up

• Focus on using Fitnesse to communicate with your
  customers first
• Then use Fitnesse as a regression testing tool
• Having Fitnesse tests shouldnt be an excuse not
  to write unit tests

31
Wrap-up

• Fitnesse Resources
• Fit for Developing Software by Rick Mugridge and
  Ward Cunningham
• Fitnesse website (http//www.fitnesse.org)
• Fitnesse mailing list (http//groups.yahoo.com/gro
  up/fitnesse)
• Fitnesse tutorials (http//www.cornetdesign.com)