Fitnesse and .NET

1. Fitnesse and .NET Achieving Customer Zen With Fitnesse Achieving Customer Zen with Fitnesse and .NET

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 don’t take care of the customers, maybe they’ll stop bugging us

4. The Customer Problem • Customers aren’t developers • Developers aren’t (usually) customers • Customers don’t 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? [Test]public void CreateRoomAddsRoomToRoomList(){ Assert.AreEqual(0, chatApp.AvailableRooms.Count); 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 shouldn’t 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/group/fitnesse) • Fitnesse tutorials (http://www.cornetdesign.com)