82 lines
4.3 KiB
Plaintext
82 lines
4.3 KiB
Plaintext
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][#wikiserver]]
|
||
* [[Test execution engine][#testsystem]]
|
||
* [[System under test][#systemundertest]] (SUT)
|
||
* [[Reporting engine][#testreporting]]
|
||
|
||
{{{ ,---------------.
|
||
| Wiki Server |<-------------.
|
||
`---------------' v
|
||
| ,-------------.
|
||
| | Reporting |
|
||
v `-------------'
|
||
,---------------. ^
|
||
| Test System |--------------'
|
||
`---------------'
|
||
|
|
||
|
|
||
v
|
||
,---------------------.
|
||
| 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:
|
||
|
||
* JUnit support
|
||
* [[System configuration][#systemconfiguration]]
|
||
|
||
!2 Wiki server !anchor wikiserver
|
||
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][<UserGuide.AdministeringFitNesse.ConfigurationFile]]. 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:
|
||
|
||
* fitnesse: Basic server setup. Configuration classes are also here.
|
||
* fitnesse.authentication: authentication features for Responders
|
||
* fitnesse.html.template: utilities for page creation, mainly Velocity templating
|
||
* fitnesse.http: HTTP protocol handling
|
||
* fitnesse.resources: static resources, served under ''/files/fitnesse''
|
||
* fitnesse.responders: the responders, handlers for
|
||
* fitnesse.socketservice: low level connection handling
|
||
* fitnesse.testrunner: code for starting test systems and feeding wiki page content to the test system(s), used from the test and suite responders.
|
||
* fitnesse.wiki: wiki page handling
|
||
* fitnesse.wikitext: Wiki text parser
|
||
|
||
!2 Test execution engine !anchor testsystem
|
||
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:
|
||
|
||
* fitnesse.testsystem: Test system main code.
|
||
* fitnesse.testsystem.fit: Fit test system code (client side)
|
||
* fitnesse.testsystem.slim: Slim test system code (client side)
|
||
|
||
!2 System under test !anchor systemundertest
|
||
The system under test consists of the user code running in (normally) a separate process.
|
||
|
||
The following packages are part of this subsystem:
|
||
|
||
* fit: The FIT server
|
||
* fitnesse.slim: the Slim server
|
||
|
||
!2 Reporting engine !anchor testreporting
|
||
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:
|
||
|
||
* fitnesse.reporting
|
||
|
||
!2 System configuration !anchor systemconfiguration
|
||
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):
|
||
|
||
* Component(!-ComponentFactory-! factory)
|
||
* Component(Properties properties)
|
||
* Component()
|
||
|
||
The properties contain all configuration properties, read from file and command line.
|