I'm attending the second meeting of the reorganized Maryland Agile/XP group - it's actually feasible for me to attend meetings that are held here in Columbia, MD. I'm marginally familiar with FIT - I've looked at the port that's been done for VW. It's a small group - 9 people including myself. So anyway - we have David Chelimsky from ObjectMentor presenting FitNesse.
Where did the name come from? First off - it's not a coverage tool. The problem with FIT had been that it could be difficult to set up - command line, hard to use - especially since the end users of it are supposed to be acceptance testers. FitNesse is supposed to be FIT with Finesse - a way to make the tool easier to use for the target audience.
- Unit tests - for the developer, not for the user community
- End users need to be able to specify (and test) their requirements
A common way to set these tests up is in a spreadsheet. What FIT does is set these things up in HTML tables. The idea is to set it up in a way that the business user will easily comprehend. So the end user makes assertions (enters data), and the back end reads, tests, and displays feedback. What's the problem? No one likes writing HTML. FitNesse makes that easier by using Wiki style markup. The developer needs to write adapters that push between the html tables and the back end application. (Small aside - this is easier in Smalltalk, since that back end application is live - like any other Smalltalk app).
In general, Fitnesse is a wiki and acceptance test server. To create tests, you create new Fixtures - fixtures are a test construct. Heh - immediately, the demo ran into a compile time issue with Java. Meanwhile, I've picked up the Fit image I last looked at in January and am mucking about with it. Ahh, Smalltalk. What would be cool would be a FitNesse port over to WikiWorks or SmallWiki - what I've got is all based on a simple servlet (i.e., a lot less user friendly than a Wiki).
So - back to the demo. The idea of FIT is that end users can specify tests with expected inputs and outputs. With the data specified in HTML tables, the inputs and (expected) outputs are easy to see, and easy enough to capture on the back end. I have no easy way to get a screen shot of what's up on the screen (and the Fitnesse server he's running looks quite nice).
I really need to spend some time making this work with WikiWorks, so that I can slap examples up on the Wiki. What about implementations? There's Java, Python, Smalltalk, Ruby, .NET. So, more on FitNesse - there are RowFixture objects as well as the ColumnFixture ones (the tables, above). This allows you to specify a collection of data that should all satisfy some condition (i.e., a #select: in Smalltalk). Or for that matter, any operation on a collection of datums.
What's the value of all this? You can talk to end users without having to delve into the code level with SUnit - you can remain up at the business level - which is the appropriate level for acceptance testing. I guess my only question is at the Wiki user level - my experience - even with highly technical users in the audience - is that a small subset of your audience will actually edit content. I'd have to see it in action with actual business users to form a final judgement though- maybe business users who feel comfortable dealing with spreadsheets would be ok with it. David's experience is that business users don't interact with it that much - but system testers (from the Q/A group) do.
The audience discussion was interesting as well - focusing on the difficulty of bringing agile methods into a shop. The consensus seems to be that the hardest thing is to convince your developers - management is actually a lesser problem. From there, it went into a discussion on open source and licensing. I love a good argument :)