Does FitNesse or FitSharp support a general-purpose configuration file?

528 views Asked by At

I know there is a plugins.properties file for configuring the FitNesse environment and customizing it, and that FitSharp supports a suite configuration file for certain environment settings. But does FitNesse or FitSharp support a general purpose configuration file, for setting symbols or markup variables?

The reason I ask is that I'm using RestFixture, a plug-in that allows calls to RESTful web services. A RestFixture table takes the host URL as a fixture argument. I'd like to move the host URL out of the test pages into a configuration file, so that the test pages are identical in different environments, such as dev, test and production.

Defining a markup variable in the root page gets me most of the way there but I'd prefer to move the variable out of any pages entirely.

By the way, I'm using the .NET port of RestFixture, RestFixture.Net, so I'm really looking for a solution that applies to .NET / FitSharp.

2

There are 2 answers

0
Simon Elms On BEST ANSWER

It turns out the plugins.properties file is a general-purpose configuration file.

I had read the FitNesse User Guide page about the plugin.properties file: http://www.fitnesse.org/FitNesse.UserGuide.AdministeringFitNesse.ConfigurationFile I took it to mean that the plugin.properties file only supported the specified built-in properties. However, there was a little note at the bottom which I missed:

Other properties

There are more properties which can be used to tweak parts of FitNesse:

...

  • Any variable that can be defined on a wiki page.

I experimented and found that any key-value pair in the file, of the form key=value, can be read in a test page.

Some notes about usage:

1) It appears that lines in the plugins.properties file starting with # (hash), // (two forward slashes), ; (semi-colon) or :: (two colons) are all treated as comments. Or, more likely, they aren't comments per se but just don't cause any errors;

2) Backslashes in the plugins.properties file need to be escaped by doubling them. eg "C:\FitNesse" should be written as C:\\FitNesse;

3) To reference a property from the plugins.properties file in a FitNesse test page use the FitNesse markup variable syntax: ${property name}
eg ${Theme}

4) Environment variables can be included in the plugins.properties file, using the FitNesse markup variable syntax. eg FitNessePluginsDirectory=${FITNESSE_HOME}\\Plugins, where FITNESSE_HOME is an environment variable.

1
Koen Prins On

Running the same tests on different environments is archieved by using symbolic links.

As you are aware, you can set a variable for all the tests in a suit by putting it on the suite page:

---
Suite
Help: Suite to contain tests for local testing
---
!define targetenvironment {http://localhost:8080}

Build this suite like this, so without any nested pages. Also build another suite page with the same property in it but with a different value.

---
Suite
Help: Suite to contain tests for local testing
---
!define targetenvironment {http://192.168.10.1:8080}

Now build your testcases in a third suite and use this property as, per your example, the target.

Finally, go back to your first suite page and go to the page properties, where you can fill a Symbolic link, you basically instantiate the test suites. Now when running this suite page, the target property is filled in the tests. When doing the same for the second suite page, you will find that in the tests, the target property is filled using that value.

The Suite .wiki file would now look like this:

---
Suite
Help: Suite to contain tests for local testing
SymbolicLinks
  TestSet: .SuiteContainingTests
---
!define targetenvironment {http://localhost:8080}

And the suite containing tests can be seen in the browser.

However, the tests are the same and no matter where you edit them (from suite 1, 2 or 3), you will always edit the same files.