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.

“On the other hand, while FIT/FitNesse community is moving firmly towards using domain objects directly in acceptance tests and reducing the amount of glue code, to eliminate translation between layers and promote domain-driven design, Concordion model is stuck in requiring you to create an explicit test method for every verification in the fixture”

I find that that to be a very good thing. Coupling domain models to FIT documents becomes a huge drag on refactoring.

Also, the way that an external user or business expert thinks about the domain and the way that a system *implements* the domain so that it can simulate it are quite different. For example a business expert will usually model the domain by categorisation while a system implements the domain by composing objects that collaborate. Trying to use the same model for both aspects of the system makes for a very brittle system with an unnatural architecture in my experience. FIT fixtures act as a good translation layer that maps between how the business expert thinks about the domain and how the system implements the domain.

“This smells to me of a hand-over of tests from business people to developers at some point, which is a practice that I don’t approve at all.”

Again, from experience I can say that if this does happen it has nothing to do with Concordion; it’s an organisational problem. Developers and business experts should collaborate on writing the documents, just as with FIT. And, again just as with FIT, the developers should help the business experts format and organise the documents so that the test fixtures pick them up.

The test documents do not have to sit alongside the Java code. They just have to be named and collected into directories so that they can be found as resources at runtime when the root directory containing the documents is added to the Java class-path.

One other plus point: Concordion has an excellent web site. A lot of the tips on that site apply just as well to FIT.