4 Scenario Tables - essenius/FitNesseFitSharpFeatureDemos GitHub Wiki

We first saw scenario tables in GameManagement, where they were introduced to eliminate duplication in script tables. You can see them as macros: the behavior is the same as if the content of the scenario would have been copied over in the calling script. In a script, you can’t see the difference between a scenario and a fixture function until you execute the page: a scenario will allow you to expand it.

Declaring Scenarios and Parameters

We saw before that scenarios can be defined in a similar interposed way as you specify function calls in script tables. Here is an example using the Temperature Fixture we introduced earlier:

|scenario|temperature|input |is|fahrenheit|F|celsius|C|kelvin|K|
|check   |convert    |@input|to|F         |@fahrenheit         |
|check   |convert    |@input|to|C         |@celsius            |
|check   |convert    |@input|to|K         |@kelvin             |

This scenario provides you the capability to do three conversion checks in one line:

Use the scenario in a script table

|script     |temperature fixture       |
|temperature|20 C|is|68|F|20|C|293.15|K|
|temperature|32 F|is|32|F|0 |C|273.15|K|

Note how you refer to parameters in the scenario body by prepending an @.

In the first call, the scenario substitutes @input with 20 C, @fahrenheit with 68, @celsius with 20 and @kelvin with 293.15, and then it executes the next lines. Since it was called by a script table bound to the temperature fixture, it runs under that context so it has access to the fixture method ConvertTo. It executes all three checks and returns.

Another way of declaring scenarios is the parameterized style. Then you place an underscore at every point where you want to use a parameter, and specify them all at the end. You call it in the same way as before.

|scenario|temperature _is _ F _ C _ K|input,fahrenheit,celsius,kelvin|

It is good to be aware of is how FitNesse resolves the scenario parameters, because there is a peculiarity. It is easiest to show it via an example. We define a scenario with two parameters param and param1 and do a check on those, like we did before. The result may puzzle you:

|scenario|test with|param  |and|param1|
|check   |echo     |@param |this      |
|check   |echo     |@param1|that      |

!|script  |Echo Fixture |
|test with|this|and|that|

Instead of substituting the value of param1, it substituted the value of param and appended 1. You can force use of param1 by surrounding it with curly braces:

|check   |echo     |@{param1}|that      |

Executing Scenarios in Decision Tables

Typically, scenario tables are executed from script tables. But it is also possible to use them in decision tables. In a nutshell, you define a scenario, and then you define a decision table with the name of the scenario, and the parameters as the columns. To make it work, you need to ensure that FitNesse knows which fixture to obtain the script commands from; a suitable way of doing that is defining a library table. You can also insert a script table of one line, with just the declaration. Here, we use the same scenario as in the previous section, but we call it as a decision table:

!|Library          |
|TemperatureFixture|

|scenario|temperature _ is _ F _ C _ K|input,fahrenheit,celsius,kelvin|
|check   |convert                     |@input  |to  |F  |@fahrenheit  |
|check   |convert                     |@input  |to  |C  |@celsius     |
|check   |convert                     |@input  |to  |K  |@kelvin      |

|decision:temperature is F C K  |
|input|fahrenheit|celsius|kelvin|
|20 C |68        |20     |293.15|
|32 F |32        |0      |273.15|

Running the test should give the following result. Notice how the decision table cells are blue. This is because the scenario didn’t evaluate any tests, so it is marked “ignored”. The result check was done after the scenario had completed.

If you do evaluate tests in the scenario and at least one of them fails, then the lines turn red. To show that, add the following line to the scenario table, and rerun the test:

|check       |convert    |0c    |to|c          |1                     |

Remove the failing line again, and create another scenario table that does a single calculation from one unit to another and returns the result. Then we create a decision table that uses this scenario:

|scenario|Convert table _ _ _ _|input,from,to,result?|
|$result=|convert|@input|@from|to|@to|

|decision:convert from to|
|input |from |to |result?|
|20    |C    |F  |68     |
|32    |F    |K  |273.15 |

Suppose we want to create a decision table that only checks whether the Celsius to Fahrenheit conversion works as specified. Using above scenario, we would have to repeat the same values for the parameters from and to in all rows. To eliminate this duplication, it is possible to specify those parameters in the header, using the given keyword:

|decision:convert table|given|from|C|to|F|
|input                 |result?          |
|20                    |68               |
|0                     |32               |
|100                   |212              |
|-40                   |-40              |

See also the FitNesse User Guide on Scenario Tables

Scenario tables are important building blocks that can also be used to enable BDD in Plain Text Tables