Test Driven .NET Development with FitNesse

In view of the fact that FitNesse works like a web server, it's only natural to think about setting up a single central test server so that team members can use the server from any machine in the network with a browser.

Technically, a single FitNesse server is capable of supporting a multi-user environment. FitNesse has an internal version control system that keeps track of test revisions, and it automatically saves a backup when pages change. Old versions are archived into ZIP files. It can also track and authenticate named users.^[24] However, FitNesse cannot automatically pull files from an external repository and commit them - you will have to write scripts for that yourself. So, if you want a central test system, you will probably want to set up a periodic build on the same machine, so that the latest code is always available for testing. Because tests are executed using an external program, no object code is cached and you just need to update the DLLs for tests to pick up the latest version of your code.

	How secure is FitNesse?
	I find that it is easier to secure FitNesse at the firewall or load balancer level than at the application level. FitNesse is not a high-load general-purpose web server: it is a specialised web server intended to help people to write tests more easily in a collaborative environment. So I recommend that you do not count too much on the service itself providing top-notch security.

Although this setup might seem like the natural choice, in practice it works only for small teams. FitNesse does not perform well when people are running tests simultaneously. It was designed to make test management easier, not to be a scalable and robust general-purpose web server. If the central system has a separate build process then developers have to commit incomplete or untested code into the main branch for the server to see it. Another option would be to allow developers to upload their DLLs to the test server, but this is only practical for the smallest teams. Even with only three or four people uploading DLLs, there can be a lot of problems due to version conflicts.

Another option is to use one central server for collaboration but execute tests on local FitNesse installations on developer machines. The central server coordinates updates and allows FitNesse on developer machines to take the latest test scripts using a wiki import. Tests are never executed on the central server, so there are no issues with server code builds nor with concurrent test runs. Developers can import test pages to a local server. Instead of one Edit button on the left, FitNesse shows two buttons for imported pages: Edit Locally and Edit Remotely. These two buttons enable developers to update a test script just on their machine or globally.

To import tests from a remote wiki you first create the page to serve as a root for the import hierarchy (putting !contents -R as the page content might be a good idea; see Group related tests into test suites). Then go to page properties and enter the remote wiki URL in the URL field in the “Import Wiki” section. You can import an entire hierarchy or any sublevel (just point to the correct subwiki URL). For more details of this feature, see http://fitnesse.org/FitNesse.UserGuide.WikiImport

This approach requires an identical setup for local FitNesse servers on all developer systems, in order to avoid problems with different disk paths to DLLs on various machines.

Since different version control systems are used for the test scripts (central FitNesse server) and project code, occasionally there are version conflicts between code and tests if several people are working on the same modules at the same time. So developers should edit the test scripts locally and then, when all code changes are complete, send the updates to the central server. In practice, local test updates often do not find their way back to the central server. However, with a bit of discipline, this can be a good setup for a smaller team.

Since most team projects use a version control system for code anyway, another common approach is to use the version control repository for storing tests instead of the central server. Test files (and often the entire FitNesse server setup) are stored in the main version control system, along with the source code. Developers start FitNesse from the local copy of the repository, and run tests locally on their machines.

The benefit of this method is that there is no conflict between code and test script versions. Everything is in the same repository. When the project folder is committed to the version control system, test scripts are committed too. Test scripts are plain text files, so modern version control systems can merge most concurrent changes correctly. This also makes maintenance easier, because there is just one code repository to back up. Finally, because the FitNesse server is also included in the repository, relative paths to project DLLs are always the same. These issues may not be important for a smaller team, but make a huge difference for larger teams.

The downside of this method is that the internal version control system in FitNesse starts getting in the way. Automatic archiving just causes headaches by polluting the version control with hundreds of ZIP files. Some very useful FitNesse functions like test refactoring simply cannot be used in a folder-based system like CVS or Subversion. FitNesse deletes and moves complete test folders during refactoring, including hidden .cvs and .svn files, which completely confuses folder-based version control systems.

Also, not having a central server leaves people like business analysts and customers outside the loop, because they typically do not have tools to access the version control system (or cannot be bothered to start FitNesse locally on their machines). This can be solved with an additional “central” test server for people who cannot run FitNesse on their machines. The central server is not used for wiki imports, but acts as a documentation reference. It can also be used by the continuous integration server to verify the build (see Continuous integration).

In any case, if tests are kept in an external version control repository, you should turn off internal archiving by adding -e 0 to the command used for starting FitNesse. To avoid lots of reports about conflicting changes, it is also a good idea to exclude ErrorLogs and RecentChanges directories (in the wiki) from version control.

If you use a central server backed by an external version control system, it is a good idea to restart FitNesse after tests are updated. Although the DLL code is not cached, FitNesse caches test scripts and other page content. Unless the server is restarted you might not see some updates straight away.

It might also be a good idea to configure the central server as a Windows service (see Can FitNesse start automatically with Windows? ), so that it loads automatically and that other services can restart it when needed.