Execute

When the FitNesseRun task runs an Execute job, it expects all fixtures and test pages to be present in the Data folder. It also expects to find FitNesse itself somewhere in the folder tree (can also be the folder itself). If you don't use the FitNesseConfigure task, you should also take care of creating FitNesse's configuration file plugins.properties beforehand in the Data folder. A convenient way of preparing all this data is using Azure DevOps' Universal Packages.

What I typically do for my projects:

• Create a universal package for FitNesse (version convention is converting the release date that FitNesse uses for its version into a semantic version, e.g. 2019.4.21), and upload it to Azure Artifacts.
• Include a Universal Package download task in your Azure Pipeline.
• Make universal packages for each fixture that you want to distribute separately. For isolation purposes, a good convention is to create folders for every fixture including their dependencies, so that different fixtures do not get dependency conflicts. Typically, I include these folders in the package so that the download task can simply use the current directory as the target directory.
• Make universal packages for each test suite that you want to distribute separately. Make sure that your test pages refer to the fixtures in the right way - relative to the current directory, including the fixture's sub-folder name.
• Make universal packages for every plugin that you want to make available separately. Also include a partial plugins.properties file (naming convention: plugins.properties.pluginname, where pluginname is the name of the plugin) to activate the plugin if required.
• Download FitSharp via a NuGet download task

You can also choose to combine fixtures and test pages in single packages if that is easier. The end goal is to have a structure like this before you run FitNesseConfigure (each color indicates a different package content):

Configuring it this way implies you need to set the path in your test suites as follows

!path "ExampleFixture\ExampleFixture.dll"

|import|
|ExampleFixture|

If pi.jar is a classic plugin containing a class called PiSymbolType that you want to expose, plugins.properties.pi should contain:

SymbolTypes=PiSymbolType

Call

In Call mode, FitNesseRun relies on an already running instance of FitNesse. How that instance is maintained varies per use case. For example, the fixtures and test pages can be deployed via an agent on the machine that runs FitNesse, or a remote copy facility can be used.