FitNesse is a wiki server. It's also a test execution engine.

In this section the application structure is described. The application can be divided in four main components:

   |  Wiki Server  |<-------------.
   `---------------'              v
           |               ,-------------.
           |               |  Reporting  |
           v               `-------------'
   ,---------------.              ^
   |  Test System  |--------------'
|  System Under Test  |

The wiki server is the component responsible for serving the web pages and handling user requests. One of the operations is starting a test run. This will start the system under test with some extra code: the Fit or Slim server. The output of the test run is stored to serve the page and test history pages.Next to the main components, there are a few extra features:

Wiki server

The wiki server is the first thing a user sees when starting FitNesse. The most notable class is the Responder. Responders can be configured via the configuration file. Per request a responder is created. The type of responder depends on the URL sent to FitNesse. By default the WikiPageResponder is loaded.

The configuration of a running FitNesse server is maintained in the wiki module, in a FitNesseContext instance. This context is configured at system startup and does not change during the lifetime of the application.

The following packages are part of this subsystem:

Test execution engine

The Test system subsystem is responsible for executing pages: starting a SUT and interpret page content. By default 2 test systems are present: good old Fit and Slim. Custom test systems can be configured via the TestSystems configuration property or a Plugin class.

The following packages are part of this subsystem:

System under test

The system under test consists of the user code running in (normally) a separate process.

The following packages are part of this subsystem:

Reporting engine

The reporting facility is responsible for passing on test system output to the browser, but also for maintaining the test execution history. Reports manifest themselves as test system listeners: they connect to events resulting from test execution).

The following packages are part of this subsystem:

System configuration

Configuration of responser, wiki symbols, test systems, reporting and more can be done via either a Plugin class or entries configured in the configuration file. 

FitNesse uses are generic way to construct objects from (configured) classes: a ComponentFactory. The component factory knows about the configured properties and is able to create instances based on class name. The following constructor signatures will be looked for (in order):

The properties contain all configuration properties, read from file and command line.