In a previous post I introduced a project I'd started with my friend Andy Palmer.

We simply wanted to have a way of journalling our efforts on a new opensource project (don't try and download what's on the public repository - we're treating that as a spike and will be making the latest code available once our first story is complete). We decided that the best way to journal our efforts would be by recording a video of our development sessions.

When I first heard of the "Given When Then" structure for writing acceptance tests, I knew instantly that it was a better way of writing executable examples (wrapped in the structure of an automated test to reduce ambiguity). It was presented by Dan North and Joe Walnes at XP Day 2006

Since then a number of frameworks have risen up using that structure. Many of these can be written in plain text. Despite this, there are still many teams using FitNesse and the new table parsing Test System called SLIM. For this reason - and because I find the "includes", variables and hierarchical wiki features of FitNesse useful I wanted to give FitNesse users the opportunity to use "Given When Then" style whilst enjoying the benefits of FitNesse. Through a spike that I did about 18 months ago, I got positive feedback from several people. One of those was a client who asked me to help them use the approach.

I've been secretly working on something... well, it's not that much of a secret... It's a new Fit Fixture for Given/When/Then acceptance tests (or BDD style tests). Andy Palmer and I have been writing it in what spare time we have...

Part of it involves finding classes (potentially written by someone else), instantiating them and returning them for use... Today we took the class that does that and refactored it to death... until it looked like this.

Firstly, my thanks to Gojko Adzic for giving such a rapid response on the FitNesse mailing list to help me solve the problem I encountered getting my .NET assemblies loaded in FitNesse .NET...

After at least 2 years of doing absolutely no .NET work, I started working with a .NET team this week, helping them to use FitNesse.

Trying to run my test for the first time, the FitServer.exe just wasn't finding my assembly... HelloFitNesse.dll

When doing Acceptance Test Driven Development, one of the things that people find hard to understand at first is the nature of an acceptance test.

In the process of teaching it over the last few days, combined with my own experience and some of the discussions during the Agile Alliance Test Tools workshop I've found another way of helping people to understand how to write 'good' acceptance tests.

One of the difficulties introducing FIT or FitNesse to teams is often helping them understand the applicability of the three core fixture table styles.

ActionFixture, RowFixture and ColumnFixture are useful as identifiers but aren't great at communicating how they are applied.

Instead, I suggest that the team think about the purpose of the test. Is it trying to communicate flow, structure or conditional characteristics.

Nat Pryce shares some valuable lessons in using FIT

Lessons include:

* Know your Audience
* Nobody in the Team "Owns" the Specifications
* Intersperse Explanatory Text
* Reuse Fixtures Between Many Specifications
* Refactor Fixture Classes Very Aggressively
* Refactor the Specifications
* Don't Drive Business Objects Directly

[textile]And a little help from CruiseControl... Check out "Jeffrey Palermo's solution":http://codebetter.com/blogs/jeffrey.palermo/archive/2005/09/13/131922.aspx

We created a new project in CruiseControl.Net to watch the wiki. Call it WikiWatcher. This project uses "filesystem" as it's source control to watch. We point this at the FitNesse directory, and CC.Net will react when any of the files there change. CC.Net then kicks of a Nant script, and that gives us all the power we need.

Cheers Jeffrey.