5 BDD Using Plain Text Tables - essenius/FitNesseFitSharpFeatureDemos GitHub Wiki

We already saw how to use the SLIM test table types such as script tables, decision tables, query tables, table tables and just now scenario tables. There is an alternative to using the pipe symbols to specify tables, and that is using the plain text table.

The format allows FitNesse to support of Behavior Driven Development (BDD). This is a specific type of ATDD, which uses the Given-When-Then format to specify test cases. It is also the basis for the Gherkin language as used by the tools Cucumber and SpecFlow. This format can be mapped easily to Arrange-Act-Assert, but it tends to be easier to grasp for business oriented people, since the behavior is at the center, and not the testing. BDD is about focusing on finding areas where there is a lack of understanding, and clarifying those via examples. But from a technology perspective, the concepts are quite similar.

Here is an example how we would translate one of the earlier examples in this chapter into BDD:

• Given a temperature of 20 C
• When I convert it to Fahrenheit
• Then the outcome should be 68.

We can represent that in a FitNesse test page by using the plain text table:

![ script
Given a temperature of 20 C
When I convert it to Fahrenheit
Then the outcome should be 68
]!

As can be seen, a plain text table starts with a line containing ![ script and ends with a line containing ]!. Combine plain text tables with the use of scenario tables (which you can hide into scenario libraries), and you can create powerful and very easy to read test cases.

Each line of the plain text table will be executed as a normal table would. It will try to match scenario tables as well as fixture code, and execute these when a match is found.

Note that plain text tables are literalized tables, so most wiki markup does not work inside them.

Here is the complete test page including the scenarios that connect the test to the fixtures:

Plain tables can be used to create BDD style tests in the given-when-then format which tend to be better understood by business oriented people.

!*> Scenarios and plumbing
|library|
|echo fixture|

|scenario|Given a temperature of _|temperatureIn |
|start   |Temperature             |@temperatureIn|

|scenario|When I convert it to _|scale |
|$output=|Value In              |@scale|

|scenario|Then the outcome should be _|expectedOutcome         |
|check   |echo                        |$output|@expectedOutcome|
*!

![ script
Given a temperature of 20 C
When I convert it to Fahrenheit
Then the outcome should be 68
]!

Expand the lines to see what it did behind the scenes:

You can even support the use of ‘And’ by adding the following scenario table:

|scenario|And _|premisse|
|@premisse              |

With that, the following test will also work:

![ script
Given a temperature of 20 C
When I convert it to Fahrenheit
Then the outcome should be 68
And When I convert it to Kelvin
Then the outcome should be 293.15
]!

This works because scenario substitution is done recursively:

The advantage that this approach brings you is that you can focus the discussions with the product owner on a Given-When-Then style specification of test cases, and you can worry later about how to exactly implement that in fixture calls. You have introduced another layer of abstraction that allows you to immediately enter the specifications into FitNesse, and show that those specifications are met by simply executing them.

See also Plain Text Table in the FitNesse User Guide.

These were the key Wiki features. Let's recap in the summary