Table of Contents |
---|
Fixture 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 | ||||||||||||||
|
|
|
Since a fixture is a Java class, when GreenPepper executes the example, it will try to match the fixture name with a class name.
What about packages?
Usually, Java classes are found inside a package and we can explicitly load a class via the package name.
An explicitly imported fixture | ||||
---|---|---|---|---|
|
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 | ||
---|---|---|
|
When GreenPepper will search for fixtures in the code, it will look into all the packages specified in the import tables.
Example of fixture name with implicit import | ||||||
---|---|---|---|---|---|---|
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 | ||||
---|---|---|---|---|
|
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 word for the fixture name and make 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 |
Note |
---|
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 fixture 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 | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
and
will both match
|
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 | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
An example with two parameters | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Rule validation (Rule For)
Definition
Definition |
---|
The RuleForInterpreter is used to express concrete and measurable business rules.
|
Specific keywords for expected values
GreenPepper offers a list of useful keywords to support the Business Expert.
Empty cells | When a test cell is left blank, GreenPepper only shows the returned value |
---|---|
error | When you expect an error, specify it in the cell to test that particular behavior |
Coloring
GreenPepper will visually show the test result by coloring each testing cell:
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
When the expected value matches the returned value, the RuleForInterpreter colors the cell as "right" by coloring it green. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
If the values don't match, the RuleForInterpreter colors the cell as "wrong" in red. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
If the system encounters an execution error, the cell is colored yellow and GreenPepper provides information about the error. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
If no expected value is specified in a test, the RuleForInterpreter colors the cell in gray. |
Here is an example of cell coloring:
Input Table:
...
...
...
...
Output Table:
...
...
...
0
...
...
...
Writing fixtures for Rule tables
As we've seen in Rule For definition, a table of rules is used to express business rules of the application under development.
A fixture for a table of rules defines how the specific given and expected columns of a rule table are mapped to the system under development.
This page shows the fixture code that supports the examples introduced in the Writing a Rule For specification documentation.
List Validation (List of, Set of, Superset of, Subset of)
Definition
Writing fixtures for List tables
Workflow validation (Do With)
Definition
Writing fixtures for Do With tables
Workflow validation (Scenario)
Context definition (Setup)
Definition
Writing fixtures for Setup tables
Advanced
Defining a custom system under development
Customizing GreenPepper fixture resolution
Hooking document execution
Execute specifications with command line
Examples
Guice Example
Rest fixture
Spring example
...