Tutorial - ATDD with FitNesse and C# Fixtures

It is assumed that you have already setup FitNesse with FitSharp as described in the readme, excluding the fixtures and test pages. This tutorial will incrementally build up the code (fixtures and test cases) that you can find in the repo. So should you get stuck somewhere, you can always have a look at the final code to see if that can clear up things.

I wanted to show with relatively simple examples how FitNesse can be used in acceptance test driven development as it was supposed to be used. And I created this tutorial because this is the sort of thing I was looking for when I started to learn it.

If you have any questions, feedback or suggestions please open an issue in this repo.

Setting the Scene – Creating a Player Management Subsystem

Let’s assume we are working on a player management subsystem for a game. We need to be able to record player names and their skill levels in the game. We need functions to add players, remove players, change their skill levels, and get an overview of all players with a certain level. We also want to know the total number of players.

Applying Acceptance Test Driven Development

With acceptance test driven development (ATDD), the first step of implementation is to decide how we are going to verify that the result behaves correctly. Ideally, we want to agree on that with someone from the business, to be sure that the result is what they want. We are translating the requirements into test cases.

Many people know the concept of Unit Test-Driven Development (UTDD), where you write unit tests before you write the production code. While UTDD is focused at the unit testing level, the principles apply equally well on the user story level. Tests describing those are acceptance tests, and therefore this practice is called Acceptance Test Driven Development (ATDD). Unit tests check whether a unit does what the developer wants it to do; acceptance tests check whether the code satisfies the requirements. You essentially have two cadences: the ATDD cadence on story level (several cycles per sprint), and the UTDD cadence on development task level (cycles of minutes).

Acceptance tests are where FitNesse comes in, so we will focus on the ATDD cycle. Writing FitNesse test pages together with someone representing the business has shown to be a very good way of reaching agreement. It will allow you to make sure that there is a shared understanding of the problem. After the acceptance tests have been specified, the developers go off to build the code (preferably using Unit Test Driven Development) and they know when they are done: when all acceptance tests pass. Note that it is not necessary (nor desired) for the UTDD cycle to use FitNesse as well; you can use the standard unit testing framework, and just run the FitNesse test as verification when you are done.

We will start by showing the Script Table in action.

Acceptance Testing Wiki