I heard about a tool named FitNesse, which is supposed to promote better collaboration between development, testing, and product groups.

What are your experiences with it? Does it really improve program quality? Are there any drawbacks to using it?

  • I assume you mean FitNesse (fitnesse.org)? – SHug May 18 '11 at 9:25
  • @SHug - Indeed, thanks. I edited to correct the mistake and the URL – RonK May 18 '11 at 9:38
  • I'm interested in seeing the responses.. I've never worked at a company that made use of a tool like this. – Wayne Molina May 18 '11 at 12:17
  • 1
    I am as well. I've heard about it, seen it, and we have it on our list of "look into" projects. I'd like to hear about some real world uses. – Andy Wiesendanger May 18 '11 at 14:11

FitNesse is an interesting tool. I think it can work well in some cases, and maybe not so well in others. The table-driven tests are very good for testing business rules and the like. If the product group is used to using Excel to communicate requirements, FitNesse is a really good fit.

Where I work, we're not really in a "business-y" environment, but we use FitNesse in a few places to produce "executable documentation" of some of our external command protocols. Having the docs and the tests combined in one document ensures that both get maintained well.

One thing I really like about FitNesse is the multiple language bindings. Because of this, the tests can be used as-is in the context of a re-write using a new language. Not a common scenario, obviously, but an interesting one. The fixture code acts as a "shearing layer" that allows your code and your tests to stay decoupled.

Probably the biggest weakness I see with FitNesse is the lack of tools for maintaining the test suite (refactoring, mass editing, etc). People are working on those, though.

If you decide to try FitNesse, I highly recommend reading anything you can get your hands on by Rick Mugridge (http://www.rimuresearch.com) and Gojko Adzic (http://gojko.net/ and http://fitnesse.info/, including their books. It's really easy to write unmaintainable, uncommunicative "script" tests with FitNesse, and these guys will get you on the right path.

  • +1 For both sides of the story. Also, thanks for all the useful links – RonK May 19 '11 at 11:34

We use it to test our webservices and it's doing a good job at that.

It helped us with:

  • Adding a new Database type. After adding support for SQL Server to our webservices we could just run our fitnesse tests and the results should be exactly the same as for Oracle. Helped us a lot with fixing the issues.
  • Ensuring nothing breaks during big refactors. We updated all our webservices to be asynchronous. Fitnesse helped finding a few border cases that stopped working.
  • Testing backwords compatibility. No matter what you change you should not break the Fitnesse tests.
  • Testing with old/new databases. Customers with older databases should still be able to use their webservices. Fitnesse ensures that you did not break their webservices which sometimes happens when a developer requests a field that's not in an older DB.

There are other tools that do all this but Fitnesse is working for us.

Not the answer you're looking for? Browse other questions tagged or ask your own question.