Why I don’t like Fit
I don’t like Fit. Believe me, I want to like it, I have tried to like it. I mean, Ward Cunningham created it for crying out loud, the man is a genius, so I am probably just missing something - right?
Every time I have looked at Fit, I always like the parts that handle column fixtures. They are clean and easy to read and generally does a really good job. Buth then we get to weird cousin Row Fixture which is not at all that easy to read and uncle Action Fixture which just won’t stop and finally family FitLibrary which does all good things but are utterly unreadble - which probably is due to my lack of experience, but then again wasn’t this intended for non-programmers?
Geoff Bache told me at XP2006 to look into FitLibrary and Erik Lundh suggested that I read the book on Fit. So now I have done just that, and I still don’t like Fit. As a language that is.
What the book did explain clearly, which I find the truly awesome part of Wards invention, is the idea of executable requirements written in advance. It is soo XP that you just have to love it. And I finally get why you should test the logic layer and not through the UI. Happy now?
But the book did not address all my concerns. It does not talk about the problems with version control; if you choose to work with Excel based Fit tests you will not be able to track changes as they are binary files. Neither does it suggest how Fitnesse pages are to be kept in version control. Also, all Fit formats are hard to follow if you track changes by commit messages by email.
The Fit syntax is in my opinion a table based DSL for writing acceptance tests. How many other programming languages do you regularly use that are table based? Excel? It is awesome for column based calculations which is the same as Column Fixtures, which I like. I alreay wrote that. But the rest is just … ugly.
A better solution in my opinion would be a Markdown based documentation format, where code formatted text, the indented one, is executed as tests just like tables in Fit. Could probably easily be turned into a Wiki if needed. For testdata I would use Yaml. Now if I could just find the time 
August 11th, 2006 at 13:41
My first experience with FITnesse was on a Valtech project. I had similar concerns with version control. I also had a problem with the FIT API as well. It didn’t seem to follow common Java/OO idioms (such as encapsulation). Though there are well thought out reasons for this, I just feel uncomfortable with it.
Really, the question for me comes down to: who is writing these things. If the customer/non-technical BA is, then I understand the desire for using a tool like this. But in my experience, projects that start out with the customer/non-technical BA writing the tests, end up with the developers eventually taking over the actual development and maintenance the tests. Because of this experience, my first inclination on many projects is to just skip the fancy UI and write the darn integration tests using JUnit, a tool that is known and familiar to developers.
August 12th, 2006 at 9:20
hi there,
regarding the issue of VERSION CONTROL with excel’s binary format — soon, you will be able to save excel files in XML format!!
BR, ~A
August 14th, 2006 at 13:47
Anjan,
I haven’t looked it up, but Excels XML format will most probably be enclosed in a zipped file, much like OpenDocument.
And even if it was a plain text XML-file, it would not be readable. Again, look at the XML produced by OpenDocument.
August 15th, 2006 at 10:17
Javid,
I mostly agree with you. However, I do like the abstraction Fit provides which allows specs to be written independently of the implementation.
Normally when working with JUnit, such abstractions are extracted after a lot of tests have been created.
I am very inclined to see what can be done with Ruby-based DSL instead of the tables.
August 18th, 2006 at 14:42
I think the excel format isn’t an essential part of Fit and shouldn’t be used as an argument against it.
Whoever implemented the excel reader for Fit caused negative PR for the product, because whenever you give people Office support they infect the whole process or product with the Office “philosophy”
I also agree on the importance of textual formats, but to be honest, excel is quite usable if you save the table as CSV. In fact, CSV as a syntax is very wiki-like so excel is Just Another Editor for it.
I don’t know Fit very well, but IMHO the main philosophy behind it is to use tables as a metalanguage to easily create custom languages for tests. Data in a table is already separated as tokens so the lexer phase isn’t needed when parsing the language.
Of course, as many people have pointed out, tabular syntax isn’t suitable for everything. That’s why I believe Fit will be replaced by some more general metalanguage that enables the creation of a richer set of syntaxes and maybe also provides some (partly) general purpose language for more complex test semantics.
October 2nd, 2006 at 22:01
It’s long seemed obvious to me that tables are really great for ColumnFixture-style tests and mostly get in the way for more workflow-style tests. Your point about version control is a good one too - pretty essential for tests that are going to live a long time.
Another recommendation: check out Exactor (I think I also mentioned this at XP2006). It’s a lot like Fit but without the compulsory tables and based much more around a plain text format. It’s a sourceforge project too, run by the guys at Exoftware. It has a much smaller user base though, of course.
Then there’s my own TextTest, but that works a little differently to Fitlibrary and Exactor - though it’s also grown up around the same desire to provide domain language tests for customers on agile projects.