fitnesse | FitNesse -- The Acceptance Test Wiki | Functional Testing library

For slim tests (which in this case, you are using), prepend the script table row with the show keyword. It will just output the function's return value. (true/false in case of 'click if available')

More info: http://fitnesse.org/FitNesse.UserGuide.WritingAcceptanceTests.SliM.ScriptTable

From that link:

• If the word show is in the first cell, then it should be followed by a function. A new cell will be added when the test is run, and it will contain the return value of the function.

The script below should not fail on the execution of click if available:

I believe we resolved/found the issue. It was caused by a non-concurrent safe fixture (fitnesse.fixtures.SetUp of FitNesse's own test set).

The take-away: build your own test suites directly under the FitNesseRoot directory and not below FitNesseRoot/FitNesse/SuiteAcceptanceTests/SuiteSlimTests

Some things that finally got me up and running:

1: Do not reference the executable (file ending with .exe) but refer to the .dll instead. No matter how it is compiled, trying to load the the .exe file as an assembly will always throw a System.BadImageFormatException.

2: Fish the .Net Core versions of Runner.exe and RunnerW.exe (and their dependencies) out of the NuGet package and use those instead of the older SLIM .Net runners (if you are migrating). FusionLog does absolutely nothing with .Net Core, so if there is any logging going on then you know that the process is not running .Net Core.

3: If you got the FitSharp projects from GitHub and are linking to the projects instead of using NuGet, then remove the post build actions to copy the files. Instead go to your test project Dependencies -> Projects -> fit open Properties (F4) and set the options Reference Output Assembly, Copy Local and Copy Local Sattelite Assemblies to Yes. Do the same for the FitSharp and Runner projects.

You can read a file or environment from your fixture (Java, .Net or ..) code. I created a FileFixture that reads files (sample usage). It may be of use or could provide inspiration...

The wiki, if it was started after the environment variable was set, could access it as a symbol (i.e. ${MY_PASSWORD_TOKEN}), but I don't expect you need that.

By the way: if your password token changes that often it might be better/easier to write some fixture code to retrieve the current password directly, instead of first having to store it in an environment variable or file before you start your test.

I don't believe there is an easy way to get the contents of a .wiki page in your fixture code (at least there is not supposed to be one ;-)).

Your approach of passing parameters to your fixtures is what I would recommend. But I completely understand that passing many properties in is not very nice. Especially maintaining a large list when the same list is used in many tests in no good.

What I would recommend that you create a (container) variable, some sort of map/hash, that you first fill with all the properties you need, and then pass that to your fixtures. In that way you only have to pass a single variable to tests and adding/removing properties does not affect how you call your fixtures. The variable is a slim variable which can be modified at runtime.

In my fixtures project I created a MapFixture and MapOfMapsFixture that allow you, besides checking the contents of a map, to manipulate the context of a map to define such a variable. What properties to put into it can then be defined in a (Suite)SetUp or by scenarios. The project also contains sample pages showing usage of MapFixture of MapOfMapsFixture.

For example in a SetUp page:

You can make the approach in your last table work (although I suspect you forgot to copy the last |). I guess you are using a 'dynamic decision table' in that case? I'm not a 100% sure it works out-of-the box like that, because I never use it like that. But I suspect you need to add a ? to the create Test Car column header, to indicate it is method whose value you want to retrieve instead of set.

I have implemented my own fixture that allows setting of symbols like that, so that does work ;-). And I know this works when the decision table is calling a scenario instead of a Java class directly.

I general I would recommend using a scenario with output parameters in a decision table. I'm sure that works out of the box and doesn't require anything complex in the fixtures. In columns where the name ends on a ? you can either check a value against the value specified in the decision table, or assign it to a symbol. (The scenario approach also allows you to check whether the returned value meets your expected criteria before using it further on in a test.)

I would recommend that you create multiple top level suites, one for each environment (e.g. one for testing locally and one for Azure) that defines the environment specific settings using wiki symbols (i.e. !define ...). The tests that are to be executed in all environments can be defined is separate suite that is included in each environment's suite using a symbolic link. The tests in the shared suites use the wiki symbols to get the values for the environment they are included in.

• This makes it explicit which settings are different between each environment
• All different environments are visible in the wiki
• Adding or removing an environment setting requires no (fixture) code changes
• You can add environment specific tests for each environment (just add them to the environment's suite besides the shared tests included via symbolic link)

If you are using slim you should be able to use the variable as $prefix.

Please note this is a different variable type, a slim symbol, as compared to the wiki variable you created using !define, you don’t need that define

No there is not. It is just like the Java classpath, which it configures, it defines a location where fitnesse looks for Java classes. It does not have to be a directory, it can also be a .jar, .zip or an expression with a wildcard.