Introduction

If you want a fully working example of Concordion with source code, I blogged previously on this subject with a simple Grails application here.

FitNesse puts a Wiki at the heart of its ATDD support.

But let me ask a question -

Are your customers really writing tests with the Wiki? Are they checking in changes to SVN? Are they checking the CI build is still green? Really?

Maybe they're not doing all the above, but they are writing some wiki based tests - great FitNesse is working for you.

But maybe your testers are actually writing the tests, perhaps with some help from the customer?
Maybe the customers are reviewing the tests regularly. Even pairing with the testers?

If, like me, you think that a Wiki is not key to ATDD or customer collaboration then maybe you should question the overhead of that Wiki set up. For instance how easy is it to integrate your Wiki tests with JUnit, your build system, your source control?

I know that a lot of work has been done to make this easier with FitNesse over the past year especially but it still isn't as simple as writing and running a JUnit test.

I think that ATDD tests should be as simple as writing a plain JUnit test. Those tests should also be easy on the eye and easy for a customer to read. They should also be quick and easy to change while the customer is with you.

Do we really need a Wiki ?

In my experience over the last 3 years of ATDD testers have always ended up writing the Acceptance Tests. Some have paired with the customers, and some have got customers to review the tests.

The customer has never done it on their own. This is a key assumption to why I prefer Concordion. My customers have never been aware of or used the Wiki.

Is your ATDD set up as simple as it possibly could be?

What if there was an ATDD framework that ran simple JUnit tests but still promoted the ATDD values of customer defined tests upfront, and still supported the customer feedback loop with easy to understand, well presented acceptance test scenarios that run at the click of a button?

Well there is - it's called Concordion.

Concordion - an alternative to FitNesse

I won't go into all the details of Concordion here. The Concordion website is simple, concise and well written.

Personally I found the FitNesse web site was very confusing the first time I read it. I was pleasantly surprised by the Concordion site's simplicity and clarity - http://www.concordion.org

Every Concordion test is a JUnit test. Plain and simple.

This means that Concordion tests, like JUnit tests

• have first class support in just about every build system there is going
• have first class support from just about every IDE going

There are no special integration classes for making Concordion tests "look like" JUnit tests - they already are JUnit tests.

There's no special fixture classes.

Writing Acceptance Tests

Concordion uses html to define the acceptance tests. You can start by just defining tests - you don't need to write any Java. Once the html is finished you can simply review that with the customer.

The tester can then bind that acceptance "specification" in Concordion-speak, to a JUnit test with a deceptively powerful and simple set of commands. The commands are embedded in the html in a way that is completely hidden from the customer - the html presentation is unaffected.

Html allows flexibility in how data is provided to the tests that is as rich as html (tables, sentences, lists etc.) and very easy on the eye styling.

Concordion also uses convention over configuration to link JUnit tests to the html specs in a simple and intuitive way.

In a maven project the html files sit in your src/main/resources in a package and name structure that matches exactly with your src/test/java structure.

I love the way that Concordion makes an ATDD test feel like any other JUnit test. This makes the whole framework much more intuitive than FitNesse.

Source control works like any other JUnit test in the project. There's nothing special going on.

I also found build integration was very, very simple. We use Clover code coverage reporting for our developer written tests. With Concordion, since I'm just dealing with JUnit it was very simple to integrate Clover so now our Acceptance testers have their own Clover reports to see any areas they may have missed.

How is the user collaboration experience affected?

In my experience Concordion written tests look better than FitNesse tests. They can easily be arranged in an easily navigable structure.

They can be easily changed and viewed during pairing sessions with a customer.

The tests look fantastic out of the box - better than FitNesse tests.

Essentially - I haven't missed the wiki and neither have my customers.

Summary

If your users aren't really aware of your FitNesse wiki, just the fact that you have acceptance tests that you can modify easily with them then do you really need a wiki? While the ability for your customers to define tests sounds tempting my experience is that no customer will ever really define tests in this way.

I found that what I really needed was a way to present tests in a way that made it easy for my customers to collaborate. I also wanted a really simple and easy solution that looked and felt like every other test I've written.

For me Concordion was the perfect solution.