Friday Feb 05, 2010
Why Fitnesse is evil
Whereas acceptance tests are nowadays common practice, automated
Fitnesse sets out to address all these objectives, and even manages to do so. However, it has a couple of (in my opinion) fatal shortcomings that will be addressed in this post. Moreover, an alternative based on Maven and Selenium will be put forward.
Let me first summarize the fatal flaws of Fitnesse, and address them in more detail immediately thereafter:
The whole idea of introducing an additional layer of complexity, i.e. executable Wiki pages only pays off if the business is actually involved in the creation and maintance. In practice, the added complexity of the extra Fitnesse layer is significant, whereas the business involvement for the acceptance tests is minimal. Employees tend to be busy, and so are the business. They are at best minimally interested in (acceptance) tests, let alone Fitnesse. They want working software!
What makes this even worse, is that the Fitnesse syntax is rather obscure, to say the least. Even the simplest things such as emphasizing a word or commenting out a particular snippet is far from what one is used to anywhere else, and forces non-Fitnesse guru's to consult the user guide or the internet all too frequently.
To make the aggrevation even worse, the name of the product is a total disaster. Everytime you want to do a Google search on Fitnesse issues or topics, among the first hits you'll always find health related subjects, such as going to the gym, keeping in shape, your favorite diet, etc (Google thinks you mentioned "fitness" after all).
But even in case you get acquainted with Fitnesse enough to overcome the aforementioned obstacles, there is still the peril of classpath problems lurking everywhere everytime. Classpath problems, which I normally only deal with during deployment of applications in WebSphere application server, are suddenly present almost every day during software development. There seems to be no (straightforward) way to make Fitnesse use the same classpath your IDE and Maven are using, and it usually takes many hours to figure out that you hit a classpath problem in the first place, as this monster shows up in all kinds of disguises. I honestly don't have the courage to try to estimate the hours that our team lost resolving Fitnesse classpath issues.
Then there are the exceptions thrown in the constructor of your fixtures (that wire the Wiki to your executable code). Fitnesse states in such a case that it couldn't invoke the constructor, which it also prints when the class/fixture cannot be found. This can be terribly confusing, as it actually finds the constructor, but got thrown out of it due to an exception. Remedy: always have your code in the constructor of a fixture surrounded by a try-catch clause with a syserr in it. Yuk.
And last but not least: Fitnesse is coupled to your code using its fixtures. This implies that the front-end cannot easily be integrated, and if you don't watch out, hooks in on your implementation, which means that whenever you refactor your code, there is the added danger of having to rewrite your whole integration test, as your entry point is at best modified but even likely so has disappeared alltogether.
To the rescue: Maven and Selenium
Surprisingly, most of the Fitnesse issues can be circumvented rather easily: configure integration tests with the Maven Failsafe plug-in, configure the Maven selenium and Jetty plug-in in your POM, and writing (and debugging!) integration tests becomes as simple as writing plain old JUnit tests. In addition to resolving most if not all of the fatal Fitnesse flaws, you get the following benefits for free: