Style and Taste in Writing FIT Documents
, Steve Freeman 
FIT is a framework that comes in various guises (Fit, Fitnesse, Fitlibrary), and can be used in different ways. The core principle behind writing FIT documents is to promote better communication between the stakeholders of a system. In principle, using FIT is a good thing, but in practice we find that some teams struggle to use FIT documents effectively. In this tutorial we will introduce some concrete examples of poor FIT style, and get the participants to refactor these examples to improve them.
By attending this session, you will:
- gain an understanding into how to write FIT documents that communicate well
- learn some pitfalls to avoid when applying FIT in practice
Proposed Timetable:
(10-15 mins) - Introduction, including a brief introduction to FIT, and example driven development in general.
(approx 1 hour): Laptops required. Work through a series of exercises. For each exercise, we will give the participants one or two FIT documents, and ask the participants to work in pairs to refactor the tables into something clearer. Each exercise is focused on a specific aspect of FIT document style. After each exercise we will present our proposed refactored document(s) and discuss.
(15 - 20 mins): FIT in practice. We will wrap up the session with a short presentation covering some of the practical pitfalls to avoid when applying FIT in practice. This is based on our real experience of using FIT on several projects, some successful, some not so successful.
Session History:
This session is being run at SPA 2008 -> http://www.spaconference.org/spa2008/sessions/session164.html. A non-interactive version of the material was presented at JavaZone 2007.
The Exercises:
We give the attendees an HTML file containing one or more FIT tables. The delegates work in small groups (2-3 people) to refactor the HTML into clearer FIT tables. For this they can use whatever text editor or HTML editor they choose. Each exercise is designed to illustrate different issues with FIT style.
- “Copy and Paste Workflow”. This is 2 ActionFixture tables that have some common workflow. They can be combined into a single ColumnFixture table.
- “Tangled Table”. This is a complex ColumnFixture table that has lots of permutations but differing concerns. It can be made clearer by separating the concerns into separate tables.
- “Unnecessary & Hidden Detail”. This is a table that contains unnecessary detail not relevant to the feature being described, and has detail that is hiding an implicit rule. We can make this example clearer by exposing the rule and removing the unnecessary detail.
- “Poor Naming”. This is a table that contains a detailed step by step ActionFixture to illustrate using a web search feature. We can make this example clearer by using language from the business domain instead of the implementation detail.
FIT in Practice
In this part of the session we will run through some prepared slides talking about some of the common problems we have encountered with teams that use FIT. Most of this advice can be applied to any sort of agile testing.
- Grow Your Language - teams should invent their own language for their own project
- Avoid Difficult Puzzles - make your examples specific, easy to diagnose
- Needs Maintenance - treat your tests as you would your code - refactor mercilessly
- Collaborative and Shared - collective “example” ownership, will require difficult conversations
- Avoid mini-Waterfall - a FIT document is no substitute for a conversation
- Give life to your Specifications - integrate them into your continuous integration and publish the results