FitNesse


FitNesse is a web server, a wiki and an automated testing tool for software. It is based on Ward Cunningham's Framework for Integrated Test and is designed to support acceptance testing rather than unit testing in that it facilitates detailed readable description of system function.
FitNesse allows users of a developed system to enter specially formatted input. This input is interpreted and tests are created automatically. These tests are then executed by the system and output is returned to the user. The advantage of this approach is very fast feedback from users. The developer of the system to be tested needs to provide some support.
FitNesse is written in Java. The program first supported only Java, but versions for several other languages have been added over time.

Principles of FitNesse

FitNesse as a testing method

FitNesse was originally designed as a highly usable interface around the Fit framework. As such its intention is to support an agile style of black-box testing acceptance and regression testing. In this style of testing the functional testers in a software development project collaborate with the software developers to develop a testing suite.
FitNesse testing is based around the notation of black-box testing, in which a system under test is considered to be a black box and is tested in terms of the outputs generated in response to predetermined inputs. A functional tester is responsible for designing the tests in a functional sense and expressing them within the FitNesse tool, whereas the software developer is responsible for connecting the FitNesse tool to the system under test so that FitNesse can execute the test and compare the actual output to the expected output.
The idea behind this testing method, as described in Fit for Developing Software, is that the forced collaboration of testers and developers will improve mutual understanding of the system and requirements by forcing the two groups to develop a common language as they learn to communicate together.

FitNesse as a testing tool

Tests are described in Fitnesse as couplings of inputs and expected outputs. These couplings are expressed variations of a decision table. The FitNesse tool supports several of these variations, ranging from literal decision tables to tables that execute queries to tables that express testing scripts. The most generic form is a fully free-form table that can be interpreted in any way the test designers like. All tests are expressed in the shape of some sort of table, however.
FitNesse is focused entirely on easily creating tests, allowing testers and developers to focus on creating high-quality tests rather than getting lost in the mechanics of executing a test. Given the way FitNesse works, creating tests easily involves three factors:
  1. Creating tables easily.
  2. Easily translating tables into calls to the system under test.
  3. Allowing ease and flexibility in documenting tests.
In order to meet these requirements, FitNesse leverages the wiki mechanism. Wikis classically allow for the easy and rapid creation of HTML pages and particularly simplify the expression of tables. These qualities make the basic WikiWiki language an ideal choice for a "user interface" for FitNesse: on the one hand it allows for the simple expression of very free-form tables, on the other hand it limits the contents of those tables to rather simple text. This means that the WikiWiki language can handle whatever shape of table is required for a particular test and at the same time limits the contents of those tables to alphanumeric text that can easily be mapped into a call to a piece of software. Finally, since each test in FitNesse is a wiki page it is possible to embed each testing table within wiki text; this allows a functional tester to include descriptive text with a reasonable layout quickly.

FitNesse as a software tool

FitNesse is a tool developed in Java and shipped as a single, executable jar file. The executable includes a wiki engine, an embedded web server, a testing engine and all the resources required to create a web site in FitNesse's own style.
FitNesse is focused very much on ease of use as a testing tool. As such it ships with all required components on board: upon execution the tool launches an embedded web server which allows test pages to be exposed locally or across the Internet with equal ease. The embedded server is quite lightweight and can be run from a laptop as well as full server machine.
Upon launch the tool deploys its own Wiki engine into its embedded server. This Wiki engine is similarly focused on simplicity, meaning that it does not require a backing database to run — it simply creates a file-based collection of Wiki pages which are interpreted by the Wiki engine and served by the embedded web server. The default wiki created by the tool includes the FitNesse user guide and some examples. The default document repository is created complete with everything needed to publish a default wiki in the FitNesse style.
The wiki engine is quite basic, but does offer all the basic facilities common among wiki engines: a search engine, revision history per page and a file overview. It also offers some refactoring operations that allow for deleting, moving and renaming files. In addition the wiki engine offers some test-specific facilities, such as standard buttons to run tests, ways of defining individual test pages and suites of tests and a historic overview of test results for trend analysis. Finally the engine offers some minor security facilities for locking pages and securing access to the wiki.

Test execution

Testing within the FitNesse system involves four components per test:
Of these components the software development team produces two: the wiki page and the fixture. The wiki page includes some form of decision table which expresses a test. For example, it might express tests for a component that performs division :
Numerator valueDenominator valueResult?
1025.0
1052.0
522.5

The link between the generic testing engine and the system under test is made by a piece of Java code called a fixture. In the case of the table above this code might look like this:

public class DivisionComponentTest extends ColumnFixture

The mapping between the wiki page and the fixture is a straightforward convert-to-camel case mapping. This mapping applies to all table headings and is used to identify the name of the fixture class as well as the methods of the fixture. A heading ending in a question mark is interpreted as a value to be read from the fixture, other headers are considered inputs to the fixture. Methods of the fixture are called in column order of the decision table, from left to right.

Testing engines

The actual mapping as described above is done by a testing engine. FitNesse supports two of these engines: the FIT engine and the SLIM engine.

FIT

More than an engine, FIT is a testing framework unto itself. It combines functionality to invoke tests, interpret wiki pages and generate output pages. FitNesse was originally built around FIT as a user interface, which inspired the name of the tool.
FIT is a framework that combines many responsibilities in testing rather than separating responsibilities neatly. The software developer pays a price for this fact in that fixtures for the FIT engine must inherit from FIT framework base classes. This can be inconvenient in Java, as it means that the framework claims a developer's one chance at class inheritance. It also means that a fixture, by its nature, is a heavyweight construct. These considerations have prompted the FitNesse team in recent years to move to the SLIM testing engine.

SLIM

SLIM is an alternative to Fit.
The SLIM engine is an implementation of the . Rather than combining all the elements of wiki-based testing, the SLIM engine concentrates only on invoking the fixture; it runs as a separate server which is invoked remotely by the FitNesse wiki engine. The interpretation of the wiki page and the generation of the result page is now part of the wiki engine.
The SLIM engine allows for far more light-weight fixtures which are simple POJOs. These fixtures are not required to extend or use any framework classes, which simplifies their design and allows the fixture designer to concentrate on calling the system under test properly and in the simplest way possible. It also keeps the inheritance route open, allowing fixture developers to create fixture hierarchies if necessary.

Books