I have started using “Specification by example” - using FitNess to create the executable specifications - in a project some time ago. While I really like a lot of the ideas behind FitNesse, I think a tool could do better than that. And so I started implementing a proof-of-concept of a new tool that addresses some of the problems I had with FitNesse. In this blog post, I want to explain my ideas for the new tool. The tool itself is - at the moment - only a concept and some lines of code. I will make it open source once (or if?) there is some working functionality.
Challenges with FitNesse
FitNesse saves pages in it’s own format and a directory structure that is separate from your project. You can keep this directory structure in your version control system, but it’s not obvious how you should deal with problems like merge conflicts. And, FitNesse has it’s own versioning for pages, so your version control has to ignore the history FitNesse keeps [*]. These problems can be solved, but they are sometimes a little bit annoying.
Because FitNesse saves pages in text files, there is some impedance mismatch between FitNesse and your code. Say you are refactoring some part of your system because you found a better name for a business concept. In your executable specifications, you have to change the names in two places: Your fixture code and the FitNesse wiki page. This also adds another source of errors: Your FitNesse specifications and fixture code can be out of sync. And you can only detect those errors when running the tests, which is pretty late IMHO.
To enable FitNesse to find your fixtures, you have to leak technical details - i.e. the class names of your fixtures - into your executable specifications. Of course you can teach the non-technical team members to ignore those, but it’s still another minor annoyance.
Solutions
All the problems I described above can be addressed with a single solution: Store the executable specifications as Java code. The tool I’d like to see would still have a wiki server. This server would present the executable specifications - which are Java classes - in a non-technical way, just like FitNesse. When you edit a specification, the tool would create a new Java source file and build the project.
With this approach, you have your code and your specifications in the same project structure. You can use the refactoring tools of your IDE to change the code and the executable specification - and the wiki pages will immediately reflect your changes. The Java compiler will assist you when you resolve merge conflicts. There is no impedance mismatch between specification pages and fixture code - The fixture code is the specification page.
The downside of this approach is that this system would only work for JVM based languages. You’d have to completely re-write it to support a different platform. But for me this is not a top priority issue at the moment.
Current status
I already wrote some code to test these ideas. It is far from being usable at the moment, but I am satisfied with the progress I made so far. I will put the code on GitHub once I have a working prototype - I hope this will be the case before the end of the year.
Are you interested in a tool like this? How would you improve FitNesse or other tools like it? Please contact me (contact info is at the bottom of this page) and tell me your opinion!
[*] For more information about how to configure FitNesse in your project, see How do I add fitnesse pages to version-control? on StackOverflow or this video by Bob Martin.
