Concordion VS the Fit Framework and FitNesse

Concordion  http://concordion.org/

FitNesse  http://fitnesse.org/

 

How does Concordion differ from the Fit Framework and FitNesse?

 

The Fit Framework was the inspiration for Concordion. I used it for a couple of years before I decided to develop Concordion with the following aims:

• Improved readability of documents
• More "opinionated" (scripting is actively discouraged)
• Easier to use

What I've tried to do in Concordion is place a stronger emphasis on writing specifications of requirements, rather than test scripts. When you use Concordion, the scripting needed to test the requirement is hidden in the fixture code. I've explained this elsewhere but basically the reason you want to make a distinction is that it means you can change the implementation and know that you are still meeting the requirement. Test scripts mix up the requirement with implementation details.

 

(See "Scripting Makeover" for a typical example of a FitNesse acceptance test and my take at a Concordion equivalent specification.)

 

You can write active specifications with Fit, but it doesn't make it easy for you. Because of the way Fit uses inheritance, its fixture code is cumbersome, so developers tend to write as few fixtures as possible. This leads to generic fixtures that can be used in multiple specifications. Though this sounds like a good thing, it usually means that the examples in the specifications are copy-and-paste jobs and not well-focused. Irrelevant detail causes all the problems associated with duplication as well as making the examples harder to follow. In addition, having generic fixtures tends to lead to scripting.

 

With Concordion the fixture code is much simpler and every specification has its own unique fixture. Because you're not sharing fixtures, it encourages you to focus the examples in the specifications much more carefully. To remove duplication across fixtures, you build a simple scripting API that the fixtures call into.

 

	Fit Framework	Concordion
Mapping document contents to Java code	Heading rows in tables form implicit mappings. Pros: Can work with HTML or with Excel spreadsheets. Cons: Fixture code is verbose. It can be hard to see which table maps to which class / method. Examples can only be in tables. Document authors need to be aware of the way Fit processes the document.	Explicit (but hidden) instrumentation in the document performs the mapping. Pros: Fixture code is clean and simple. Obvious what is called and when. Any HTML can be instrumented - paragraphs, lists, tables etc. Authors can focus on making documents readable without having to worry about how they are going to be processed. Cons: Requires an HTML source document.
Storage of specifications	Fit: File system Fitnesse: Wiki	In a Java source folder (I usually have folders "src", "test" and "spec"). The advantage is that the specification and its corresponding fixture are always together, and can be stored under version control with the rest of the code.
Integration	Separate runner	Run using JUnit
Platforms	Java, .net, Python, Ruby, perl, Smalltalk, C++	Java, .net, Python, Ruby Scala
Time to Learn	I don't know. It took me several weeks and the book to really understand it!	About 30 mins