6 Data Driven Tests With Decision Tables - essenius/FitNesseFitSharpGameManagementDemo GitHub Wiki

"Gee", the business rep begins, "if you look at the Setup page that initializes the players, it’s a bit wordy using a script table. Isn’t there a more efficient way to specify the start values?" And indeed, there is. We can use a decision table. Then the columns become input variables and expected results (the latter indicated with a question mark). Let’s show how that looks. Edit the Setup page and make it look as follows:

|Decision: Add Players            |
|Player Name|Skill       |Success?|
|Steve      |beginner    |true    |
|Julie      |intermediate|true    |
|Bill       |intermediate|true    |
|John       |advanced    |true    |

This is a decision table. To make the code that goes with it, create a new class in the GameManagementFixtures project and call it AddPlayers.

namespace GameManagementFixtures
{
    public class AddPlayers
    {
        private bool _success;

        public string PlayerName { get; set; }
        public string Skill { get; set; }

        public void Execute() => 
            _success = PlayerManagementDriver.AddPlayerWithSkill(PlayerName, Skill);

        public bool Success() => _success;
    }
}

The two properties PlayerName and Skill in this class correspond to two input parameters Player Name and Skill. Alternatively, you can define a setter method, which in this case would be called SetPlayerName and SetSkill. Columns to check (with question mark in the name) translate to a method with the same name as the column, here Success. The return value can differ (e.g. bool, string, int, object), The test runner (FitSharp) will then make the mapping to strings. The Execute method is called just after all setters have been called, and just before the first output function is called. We let that call the function being tested (AddPlayerWithSkill). The Success method simply returns the return value of the tested function. FitNesse processes the table row by row. It will first set all the input parameters, and then the columns to check (output parameters).

Here is the output:

For a bit more detail on Decision Tables have a look at the explanation in the Fibonacci Demo

Sometimes the flexibility of decision tables just isn’t enough. If you want to be able to vary the names of the input or output parameters, that’s when dynamic decision tables are useful.

Create a new page DynamicTableTest with the following content:

|dynamic decision: skills overview            |
|Player Name|beginner?|intermediate?|advanced?|
|Steve      |X        |             |         |
|Julie      |         |X            |         |
|Bill       |         |X            |         |
|John       |         |             |X        |

We could simply create methods for beginner, intermediate and advanced, but that would not be extendable. E.g., if we ever got a new skill “expert” then we would need to update the fixture. Furthermore, the methods would be very alike, and we don’t like copy/paste. Here is where a dynamic table comes in handy. Define a class SkillsOverview as follows:

using static GameManagementFixtures.PlayerManagementDriver;

namespace GameManagementFixtures
{
    public class SkillsOverview
    {
        private string _player;

        public object Get(string requestedSkill) => 
            PlayerIfSkill(_player) == requestedSkill ? "X" : string.Empty;

        public void Set(string name, string value) => _player = value;
    }
}

The outcome in FitNesse:

Since we only have one input parameter (Player Name) we didn’t need to bother about the name in the Set method, we just need the value. After setting all input values, FitNesse will call the Get method with the name of the column as parameter for each column where the name ends with a question mark. Now we can simply use the existing PlayerIfSkill method to return the skill of the player, which we then compare to the column name that FitNesse passed it.

There is one test table that we haven't discussed yet, and that is the Table Table, up next.