8 Cleaner Test With Library Tables And Define Table Type - essenius/FitNesseFitSharpGameManagementDemo GitHub Wiki

Sometimes there are functions that you would like to re-use across fixtures. One of them is for example echo, which allows you to assign values to a symbol. In the spirit of DRY (don’t repeat yourself) it would not be a good idea to define a function Echo in every fixture you want to use the echo function in. That is why there is the library table. This allows you to specify another fixture that can be used as a fallback source for fixture functions if it is not found in the primary fixture. We will show how that works. Create a new .NET 5 library project called SupportFunctions and add a class CommonFunctions with the following content:

namespace SupportFunctions
{
    public class CommonFunctions
    {
        public static object Echo(object input) => input;
    }
}

Update config.xml to refer to this assembly as well as the namespace that CommonFunctions resides in (changes in bold italics):

<?xml version="1.0" encoding="utf-8" ?>
<suiteConfig>
  <ApplicationUnderTest>
    <AddAssembly> GameManagementFixtures.dll</AddAssembly>
    <AddNamespace>GameManagementFixtures</AddNamespace>
    <AddAssembly> SupportFunctions.dll</AddAssembly>
    <AddNamespace>SupportFunctions</AddNamespace>
  </ApplicationUnderTest>
  <Settings>
    <Runner>fitSharp.Slim.Service.Runner</Runner>
  </Settings>
</suiteConfig>

Now add a reference to this project in GameManagementFixtures, so SupportsFunctions.dll is deployed to the build output folder. Build the solution, and create a new FitNesse test page called EchoTest under GameManagementSuite. The library table specifies that on this page, the CommonFunctions fixture can also be used as a source of fixture functions, besides the fixture mentioned in the script table. So it will grab the Echo function from CommonFunctions since PlayerManagementDriver doesn’t have one:

!|library       |
|CommonFunctions|

|script |player management driver             |
|$player=|echo  |Julie                        |
|check   |player|$player|if skill|intermediate|

Notice the exclamation mark just before the first pipe of the library table. This switches off FitNesse’s looking for page references via PascalCase names (here CommonFunctions) and inserting links if it finds them. We do not want that to happen here.

Here is what things should look like when you run the test:

Of course, you could move the library definition to the Setup page; then the function would be available to all the suite pages. But since we only need it on this page, we chose not to do that.

Some people don’t find it very intuitive or readable to use table qualifiers like Decision, Table, Query etc. You can get around that by making a mapping between fixtures and their table types once, and then you can use the fixture without explicitly mentioning the table type.

Under GameManagementSuite, create a SuiteSetup page and enter the following content in it:

|Define table type                           |
|add players             |as Decision        |
|overview                |as Table           |
|players with skill      |as Query           |
|skills overview         |as Dynamic Decision|
|player management driver|as Script          |

Now, instead of having to use: |Dynamic Decision:Skills Overview| you can simply use |Skills Overview|.

Below examples show how we did this with a few table types:

I hope that with this tutorial you got a good impression of how you can use FitNesse in your ATDD process, how you can create fixtures for it in C#, and how you can ensure that Wiki test pages can focus on the test worklow and test data, while the lower level technology integration is hidden in the fixtures. I also hope that you realize fixtures should be relatively static - you create them once, and then use use them as building blocks in your test pages.

To close off, please have a look at a few tips and tricks that might be useful when you're designing your test suites.

Questions/comments/suggestions? Open an issue!