1. Fixtures Conventions

Introduction

Even though one of the objectives of is to create a common language between the business experts and the development team, there will always be a certain degree of difference between the natural language and the programing language.

Hence comes the reason for having fixtures. Fixtures are the glue between the business expert examples and the software being developed.

When running the table, uses a fixture to mediate between the example expressed in the table and the system under test.

Collaboration demands compromise

The goal of the fixture, is to translate from one language to the other so neither has to compromise their clarity or their design to match the other. The fixture is the compromise.

A fixture is any class. It does not have to extend or implement any base class/interface.

The fixture name

The fixture name is found right next to the interpreter specification.

simple fixture name

rule for	FixtureName
..	..

list of	FixtureName
..	..

do with	FixtureName
..	..

Since a fixture is a Java or C# class, when GreenPepper execute the example, it will try to match the fixture name with a class name.

What about packages and namespaces?

Usually, Java classes are found inside package and C# inside namespaces.

An explicity imported fixture

rule for	com.xyz.stuff.FixtureName
..	..

Readability

The problem with packages and namespace and with the classes naming convention, camel casing and no spaces, is that they makes the example less readable for the business expert.

To help readability, we have the following options

Import tables

Import tables are special tables at the beginning of the document.
By using an import table we can remove the package from the fixture name thus improving the readability of the example.

an import table

import
x.y.z

In C#, the namespaces are also provided in the Import table.

an import table with namespaces

import
Sample.Application.Stuff

When GreenPepper will search for fixtures in the code, it will look into all the packages/namespaces specified in the import tables.

Example of fixture name with implicit import

import
com.xyz.mystuff

list of	FixtureName
...	...

GreenPepper will match com.xyz.stuff.FixtureName.

You can have more than one package or namespace imported in a document. Just add more lines to the import table.

an import table with multiple imports

import
com.xyz.stuff
com.xyz.otherstuff
com.xyz.yapackage

GreenPepper will search for the fixture in each of these packages until it finds a matching class.

Humanized name

Event without the package, programmatic naming conventions are not the most readable form for the name of the example.
This can be arranged by following the camel casing conventions.

Use a free form with space separating each words for the fixture name. And makes the fixture class use camel casing.

GreenPepper will match the words of the fixture name with the camel cased class name.

Camel casing multiple word fixture name

fixture name
the fixture
a fixture with a very long name becomes

TheFixture
AFixtureWithAVeryLongName

When using the humanized version of fixture naming, you must use Import tables.
explicit package won't work ex: |list of | com.xyz.stuff.the fixture name|

The fixture suffix

If you wish to clearly distinguish between your domain classes and the classes that serve as fixture, you can add the suffix Fixture at the end of the fixtures classes name.

When writing the example, you can omit the suffix Fixture from the fixture name. This keeps the example closer to the real domain.

Suffix example

rule for	bank account fixture
...	...

and

rule for	bank account
...	...

will both match

public class BankAccountFixture {
 ...
}

Constructor

A fixture can receive parameters during it's construction. You must have a public constructor that matches the numbers of parameters.

When no parameters are specified in the example, the fixture class must have a public constructor without parameters.

Empty constructor example

rule for	bank account
...	...

public class BankAccountFixture {
   public BankAccountFixture()
   { ... }
}

An example with two parameters

rule for	poker table	ante	5$	max bet	100$
...	...

public class PokerTableFixture {
   public PokerTableFixture(Ammount ante, Ammount maxBet)
   { ... }
}