Concordion is an open source tool for writing automated acceptance tests in Java

Key Features

  • Powerful, yet simple to use Concordion integrates directly with JUnit.

  • Highly readable tests Concordion acceptance tests are so readable they can double up as system documentation. And, since the tests are linked to the system, you know the documentation is always up-to-date.

  • Separates tests from implementation Tests that include a lot of implementation detail lock you into that implementation. Concordion helps you to document the logic and behaviour of your system in a way that does not lock you in.

What's special about it?

Plain English specifications

Rather than forcing product owners to specify requirements in a specially structured language, Concordion lets you write them in plain English using paragraphs, tables and proper punctuation. This makes the specifications much more natural to read and write, and helps everyone to understand and agree about what a feature is supposed to do.

Always bang up-to-date

Concordion specifications are active. Behind the scenes, they are linked to the system under test and therefore do not go out-of-date. If a change is made to the system's behaviour then the tests associated with the relevant specification will fail and let you know.

Example: Online Shopping Site

Imagine that we are working on an online shopping site, like Amazon. We are already several iterations in, but there's still plenty of functionality we can add.

1. Choose a story to be implemented

From the dozens of possible stories, the following card has been chosen for implementation in this iteration:

Story card

On the back of the card are some rough jottings about the scope:

Story card - rough scope

2. Write a story page

The story page acts as a summary of the acceptance criteria as agreed by the group. It is the output of a discussion about the story between developers, testers and the story owner / business expert.

The page is divided into sections "Automated", "Manual" and "Out of Scope". Ideally the acceptance tests will all be automated, but sometimes manual tests are needed. For example, one of the manual tests is to "check user-interface changes are consistent with rest of system"; this kind of test cannot be easily automated.

Story page

3. Write detailed acceptance criteria

Again, these are written and agreed as a group before any coding begins.

Each of the items under the "Automated" heading in the story page is a link to an acceptance test. These tests are under a different hierarchy to the stories and organised in a way that results in easily navigable documentation. If you use the right conventions, Concordion will automatically insert breadcrumbs for you.

Each page consists of a concise heading, a description and one or more examples. The breadcrumbs give you context, so you don't need to have long wordy headings and descriptions.

You'll notice that this page is pretty simple to understand and maybe looks overly simplistic. But it's not; rather than having complicated tests that test many things, you can have simple tests that test one thing at a time. Complex behaviours are defined one small strand at a time by decomposing the behaviour. The "Further Details" section at the bottom of the page lists a number of questions that you might ask about the functionality. Each question links to another (equally simple) specification and so on until you run out of questions.

Acceptance test

4. Now everyone knows what "done" means for the story

It takes some time to write the acceptance criteria; perhaps 2 or 3 hours for a 5 pair-day story. But it pays dividends in terms of focus, test coverage, and cutting scope creep. Plus, if you take care, you can build up some very valuable documentation that does not go stale.