However, when I’ve introduced Concordion it has been exceptionally well received. This has worked particularly well when shipping executable acceptance tests to be delivered by outsourcing companies and allows the onsite team to specify the acceptance criteria as well as get the senior developers and analysts onsite to design the interfaces and business service calls they expect to be called to create a failing acceptance test.

By far the biggest problem I’ve encountered with Concordion adoption (but negligible compared to FIT) has been developers trying to take ownership of the specifications, but as mentioned in other comments this is an organisational issue rather than a tool issue.

I’ve also found it extremely easy to adapt concordion to meet my particular needs. Being JUnit based you can integrate easily with enterprise tools for sourcing and reporting. This has often proved much more onerous with the other tools I’ve encountered…

I would finally commend David on his excellent diagram of the story delivery lifecycle (http://www.concordion.org/memo/StoryDeliveryLifecycle.pdf). Too often developer pick up a task and think they know what to do and never speak to the customer until it’s done. I am constantly prompting to seek feedback at every opportunity, about to write an acceptance test, speak to the customer, got a failing acceptance test in place, check with the customer, got a single acceptance test passing, demonstrate to the customer…

http://www.agileinsider.org/2010/04/natural-language-automated-acceptance-testing/
http://www.agileinsider.org/concordion-plus/

You might be able to get away with writing a handful of tests, but a suite of 500-1000 acceptance tests needs to be maintainable otherwise it will die. This requires coding skill.

In our team the testers take responsibility for defining the acceptance criteria with the customer. They read use cases/stories and convert them into Concordion specs.

A developer can then work with the tester if necessary to automate depending on the testers coding ability. The essence of the spec (user’s intentions are unaffected). So there is no handover. I think the previous commenter is right – the throw it over the wall approach can apply to any of the ATDD frameworks.

If anything because testers may rely more on developers this encourages collaboration in my team.

Tying your acceptance tests to the implementation of a system smells terrible to me. Your users’ intentions may be stable but the domain objects in your system that implement those intentions may need to be refactored many times. This kind of coupling makes your acceptance tests brittle and unmaintainable.

To me ATDD is about coding discipline with a very customer friendly facing intention based “view”. Concordion is the simplest most direct framework for achieving this for me.

I talk more about why I prefer Concordion over FitNesse here

http://www.dish2dish.com/confluence/display/NPB/2010/02/14/Why+I+prefer+Concordion+to+FitNesse

<>

It’s a matter of your approach – as always. To us Concordion is the perfect tool to adopt the Agile Testing approach we want to use.

– FitNesse results in a test scripts essentially, and we felt this would cause too much pain when refactoring was required. Whereas Concordion promotes that all the scripting is done in the fixture (Java) code, thus making code resuse and refactoring simpler.

– Concordion’s integration with JUnit makes it very simple to hook into a Continuous Integration system.

– The ‘active’ specifcations that result from Concordion are more suitable (and readable) to develop with the business than the wiki pages in FitNesse. This also lends itself more to a Acceptance Test Driven Development approach.

- Source control is considerably easier with Concordion as you’re only dealing with HTML and Java files and writing of both is done with an IDE.

We are yet to employ Concordion in earnest yet, but that is about to change as the first iteration of the new project is due to start soon. So it will be interesting to see how well it performs in a full real world environment.

I made a .NET port of Concordion that is in an alpha stage right now.

It does not have a restriction of where the specs are in relation to the fixtures (you can specify this with attributes but I’m moving that code into a config file).

I believe that with OGNL in the backend you can make calls to methods on domain objects from the fixtures if you like, at least with no more work than would be required of Fitnesse right now. While It is a nice idea to keep domain objects in the fitnesse tests we found the scripting to be very hard to maintain in the long run if code is refactored and the wiki model is a real pain to work into continuous integration.