xcfit 0.2.0

data/XCFitDemo/FitNesseRoot/FitNesse/SuiteFitAcceptanceTests/properties.xml

@@ -0,0 +1,14 @@
+<?xml version="1.0"?>
+<properties>
+	<Files>true</Files>
+	<LastModifyingUser>docs</LastModifyingUser>
+	<Properties>true</Properties>
+	<RecentChanges>true</RecentChanges>
+	<Refactor>true</Refactor>
+	<Search>true</Search>
+	<Suite>true</Suite>
+	<Versions>true</Versions>
+	<WhereUsed>true</WhereUsed>
+	<saveId>1155243419139</saveId>
+	<ticketId>-2818257665539849994</ticketId>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AcceptanceTests/content.txt

@@ -0,0 +1,41 @@
+!1 Automated Acceptance Tests: Building the Right Code
+!-FitNesse-! automated acceptance tests are power tools for fixing a broken requirements process. Skillfully applied, such tests make it possible to avoid the problems of ProjectDeathByRequirements. (Note: if you have not yet done so, you should probably first get a quick intro on !-FitNesse-! tests at the TwoMinuteExample.)
+
+!2 The Advantages of !-FitNesse-! Tests
+!-FitNesse-! automated acceptance tests have several advantages over many kinds of traditional black-box, GUI-based functional tests:
+
+ * !-FitNesse-! tests can give us feature feedback '''very early''' in the project. In fact, the tests ought to be written '''first''', so programmers can ''code to'' the tests.
+ * !-FitNesse-! tests can give us feature feedback '''very frequently'''. They can be run manually or automatically by anyone with web access to the server, as frequently as required. Every week, every day, every hour in a crunch.
+ * !-FitNesse-! tests are '''deterministic''': they either run green or red. If they run green for a given requirement, either the requirement is done and we move on to others, or the set of tests is not yet exactly right, in which case we refine them. Either way, we are '''successively refining''' the system in an orderly way. With each new test running green, we can all see the system getting better, more valuable, closer to what we need.
+ * Being based on example data, !-FitNesse-! tests '''exercise more paths through the business logic'''. When you use !-FitNesse-!, you run less risk of missing important features or functional behavior.
+
+!2 Acceptance Tests vs. Unit Tests
+If you are familiar with the emerging [[xUnit][http://encyclopedia.thefreedictionary.com/XUnit]] style of automated unit testing (e.g., using [[JUnit][http://www.junit.org]] for Java, or [[NUnit][http://www.nunit.org]] for C#), you may well wonder why both kinds of testing are necessary, and how they work together. Let's discuss that.
+
+!3 [[xUnit][http://encyclopedia.thefreedictionary.com/XUnit]]: Building the ''Code Right''
+Automated unit tests (or programmer tests, as they are increasingly called), are white-box tests that describe and verify very low-level behavior. Especially when working test-first, programmers rely on such tests to make sure that the design is sound, and that there are no defects. Such tests are built by and largely for programmers, and can be independent of functionality.
+
+If a team using [[JUnit][http://www.junit.org]] or [[NUnit][http://www.nunit.org]] to do Test-Driven Development is still hampered by a broken requirements process, they can easily end up building robust, lean, well-factored code with no business value. (This is, in fact, happening with increasing frequency.)
+
+!3 !-FitNesse-!: Building the ''Right Code''
+!-FitNesse-! automated tests are about building the right code in the first place: the code with the most business value. While programmers may be involved in writing such tests, they are not just for programmers. !-FitNesse-! tests are especially for customers, business analysts, testing professionals, support staff, management, and all other stakeholders who need evidence that the project is producing solid return on investment.
+
+!3 "Running, Tested Features"
+Ron Jeffries articulates the idea that the ultimate software project metric, the one closest to ROI, is '''[[Running, Tested Features][http://ronjeffries.com/xprog/articles/jatrtsmetric/]]'''. How many RTF did we deliver last iteration, or last month, or last release? '''Only a tool like '''!-FitNesse-!''' can answer these questions.'''
+
+Without a solid tool for automated acceptance tests, you cannot know how many RTF you produce per unit time, so perhaps you cannot easily determine what your project ROI is. Perhaps your team is headed for ProjectDeathByRequirements.
+
+!2 Consider Using Both Tools
+If you use !-FitNesse-! without using [[JUnit][http://www.junit.org]] or [[NUnit][http://www.nunit.org]] to test-drive and refactor your code, you may end up with tremendous business value, but rotten, buggy code. Even if the bugs don't kill you, this is short-sighted; it's a way of sacrificing release 3 to release 1. You have to keep the code lean and extensible to prevent code rot. Otherwise, your rotten codebase will need to be rewritten from scratch, long before it has exhausted its business value.
+
+With both tools, you can balance production and production capacity. You can deliver the features that produce highest ROI, while producing robust, clean, extensible code. You might find that you get addicted to the early, frequent feedback that automated tests provide. Your whole team could get addicted to Building the Right Code, and Building the Code Right.
+
+!2 Summary
+ * !-FitNesse-! automated acceptance tests have several advantages over traditional functional testing. These advantages are good both for requirements management and for feature verification.
+ * Only automated acceptance testing (such as that provided by !-FitNesse-!) enables you to measure [[Running, Tested Features][http://www.xprogramming.com/xpmag/jatRtsMetric.htm]], which is a key metric for measuring software project progress and success.
+ * !-FitNesse-! automated acceptance testing is a natural complement to [[xUnit][http://encyclopedia.thefreedictionary.com/XUnit]]-based unit testing. The former helps you build the right code, while the latter helps you build the code right. Consider using both tools.
+
+!2 Learning More
+If you have not yet done so, check out the TwoMinuteExample. For more information on how teams can work together with !-FitNesse-! tests to deliver better systems, see DeliveringTheRightSystem.
+
+If you are ready to start creating !-FitNesse-! pages and test tables, check out how to [[work with !-FitNesse-! wiki pages][.FitNesse.UserGuide.FitNesseWiki]] and [[create acceptance tests][.FitNesse.UserGuide.WritingAcceptanceTests]].

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AcceptanceTests/properties.xml

@@ -0,0 +1,7 @@
+<?xml version="1.0"?>
+<properties>
+	<Files/>
+	<Help>What are the advantages of FitNesse automated acceptance tests?</Help>
+	<RecentChanges/>
+	<WhereUsed/>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/ApplicationArchitecture/content.txt

@@ -0,0 +1,81 @@
+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.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/ApplicationArchitecture/properties.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<properties>
+<Files/>
+<RecentChanges/>
+<Search/>
+<Static/>
+<WhereUsed/>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/CommandLineArguments/content.txt

@@ -0,0 +1,29 @@
+!1 Command line arguments
+
+A subset of configuration options can be provided through the command line. Command line properties take precedence over properties set in the configuration file and system properties (''-Dproperty=value''). 
+
+| ''Command!- -!line!- -!parameter'' | ''Configuration!- -!property'' | ''Default'' | ''Description'' |
+| {{{-p <port>}}} | Port | 80 | The port number that FitNesse listens to.  The default is 80 because this is the port that internet browsers use by default.  If your machine already has a web server running, it will be using port 80, so FitNesse should be set up to use a different port, like 8080.{{{java -jar fitnesse-standalone.jar -p 8080}}} |
+| {{{-d <path> }}} | !-RootPath-! | . | The directory in which FitNesse expects to find its page root.  It defaults to the current directory ('.'). |
+| {{{-r <path> }}} | !-FitNesseRoot-! | !-FitNesseRoot-! | The directory in which FitNesse looks for top level pages. |
+| {{{-v }}} | !-LogLevel=verbose-! | normal | Set the system log level to verbose. |
+| {{{-l <path> }}} | !-LogDirectory-! | ''no logging'' | If this argument is not present, then FitNesse will not create access log files.  Otherwise it will create access log files in the specified directory.  See LogFiles. Please note that access logging is different from system logging. |
+| {{{-e <days> }}} | !-VersionsController.days-! | 14 | Sets the expiration date for page versions.  Any page version older that the number of days specified by this argument are considered to have expired.  Expired pages are subject to deletion.  Just ''when'' they are deleted is not specified. |
+| {{{-o }}} | !-OmittingUpdates-! | ''install updates'' | When a new version of FitNesse is run for the first time, it checks the existing environment to see if any changes need to be made in order for the existing environment to be compatible with the new version of FitNesse.  For example, if we change the icon on the upper right, FitNesse might go to the http://fitnesse.org/files site and automatically download the new icon.  Or if the format of the properties files, or of the wikipages changes, FitNesse might run through all the existing pages and update their format.  This process is called ''updating''.  Sometimes you don't want updating to take place.  If so, then use the '''-o''' argument to disable updating. |
+| {{{-a authentication-parameter}}} | Credentials | ''none'' | Enable authentication. ---- If the authentication-parameter is of the form "username:password" then single user authentication is enabled, and just that one user will be known to the system. ---- If the authentication-parameter is of the form "filename" then the file will be read.  It will consist of any number of lines of the form username:password and all those users will be known to the system. See PasswordFile for more information |
+| {{{-i}}} | !-InstallOnly-! | ''no'' | Install only, do not run fitnesse after install. |
+| {{{-c <command>}}} | Command | ''none'' | Run a Rest Command and then exit. You can find more information on the -c options at RestfulServices. |
+| {{{-b <filename>}}} | !-RedirectOutput-! | ''stdout'' | redirect command output. This is most useful in conjunction with the ''-c'' option |
+| {{{-f <config file>}}} | n.a. | plugins.properties | Load an alternative configuration file. The file format adhere's to the java standard of property files. If this option is not provided, the default file ''plugins.properties'' will be loaded if it exists. |
+
+
+!1 Java system properties
+
+Some system properties can be used to control and/or to configure FitNesse (-Dproperty=value):
+
+|''System property'' 		|''Description''|
+|{{{slim.port}}}			|If you are using [[Slim][<UserGuide.WritingAcceptanceTests.SliM]], you can also pass in -Dslim.port to hard code the port that the Slim server uses, or configure slim.port in the configuration file.  This can be used in conjunction with Jenkins Port Allocator Plugin or the reserver-network-port mojo of the Maven build-helper plugin.|
+|{{{prevent.system.exit}}}	|If this property is set to true, then the ''!-SystemExitSecurityManager-!'' is activated to catch System.exit() calls and prevent them from terminating the VM. Default is set to ''true''.|
+
+See also: ConfigurationFile.
+

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/CommandLineArguments/properties.xml

@@ -0,0 +1,6 @@
+<?xml version="1.0"?>
+<properties>
+	<Files/>
+	<RecentChanges/>
+	<WhereUsed/>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/ConfigurationFile/content.txt

@@ -0,0 +1,182 @@
+Various plugins are supported by FitNesse.
+
+!3 Overview
+Below are a list of customizations you can make via this plugin architecture.  Each plugin will require an entry in the ''plugins.properties'' file.  This should be located in the working directory of FitNesse.   If the file does not exist FitNesse will run normally.  To enable a plugin, create this file, and add the specified entries.  All plugins will require complied Java code so make sure that the class path contains an entry to locate your plugins.
+
+See also: CommandLineArguments.
+
+!3 Theme
+''required property:'' '''!-Theme-! = <theme name>'''
+
+''motivation:'' Customize the look and feel to match your liking. See WikiTheming for details.
+
+!3 Context root
+''required property:'' '''!-ContextRoot-! = <root path name>'''
+
+''motivation:'' Customize the root url of !-FitNesse-!. This is convenient if !-FitNesse-! is running behind a proxy server.
+
+!3 Wiki Page Factory
+''required property:'' '''!-WikiPageFactory-! = <class name>'''
+
+''motivation:'' By default, wiki pages are stored as files on a file system (using the !-FileSystemWikiPage-! class). Providing a custom wiki page plugin allows pages to be stored using other means such as a database. Alternatively, !-FileSystemWikiPage-! can be extended to provide custom behavior when pages are create, saved, deleted, etc.
+
+The class specified must implement the ''fitnesse.wiki.!-WikiPageFactory-!'' interface. It must provide a public default constructor or a constructor with the form:''public !-WikiPageFactory-!(Properties properties).'' The Properties define the properties defined in the configuration properties file and on the command line.
+
+!3 Versions Controller
+''required property:'' '''!-VersionsController-! = <class name>'''
+
+''motivation:'' Custom version management for file system pages.
+
+By default FitNesse makes backups of pages (as zip files). This property can be used to define version management for the wiki pages. By default FitNesse supports a Git based versions controller (!-fitnesse.wiki.fs.GitFileVersionsController-!) and a simple implementation that does not track changes (!-fitnesse.wiki.fs.SimpleFileVersionsController-!). Custom versions controllers can be defined, as long as they implement the !-fitnesse.wiki.fs.VersionsController-! interface.
+
+!3 Recent Changes
+''required property:'' '''!-RecentChanges-! = <class name>'''
+
+''motivation:'' If you have a custom versions controller installed, it's nice to see those changes on the recent changes page
+
+By default FitNesse maintains a page ([[!-RecentChanges-!][.RecentChanges]]) that keeps track of changes made to the wiki. If you're using Git versioning, it's much more convenient to just list the changes from the SCM, instead of the ones maintained in the files (let alone the potential merge conflicts). For Git, !-fitnesse.wiki.fs.GitFileVersionsController-! supports the !-fitnesse.wiki.RecentChanges-! interface, so changes of the repository can be displayed, instead of the ones maintained in the !-RecentChanges-! file.
+
+!3 Responders
+''required property:'' '''!-Responders-! = <key:class name>[,<key:class name>]'''
+
+''motivation:'' Allows functional customization.  With this plugin you can customize the way FitNesse responds to HTTP requests.
+
+The property provided should be a comma separated list of key:value pairs, where value is the name of a class that implements ''fitnesse.Responder''.  The key is used in the URL to designate which responder to invoke.  An example responder plugin might be an !-RssResponder-! that would generate RSS feeds for wiki page updates.  To do this you would first create the !-RssResponder-! to generate the RSS.  Then add the plugin property !style_code[''!-Responders=rss:your.package.RssResponder-!''].  Then to invoke it you would use a URL like !style_code(''!-http://fitnesse.org/RecentChanges?responder=rss-!'') to get a feed on all the changes made to the [[!-RecentChanges-!][.RecentChanges]] page.
+
+!4 Disabled Responder
+The !-DisabledResponder-! is provided as a way to turn off at a very deep level other responders.  Using the Responders property in the !style_code(plugins.properties), you can disable any existing responder by defining it to use the !-DisabledResponder-! instead.  For example, the following line, will disable the addChild and new responders.
+
+Responders =addChild:fitnesse.responders.DisabledResponder,new:org.fitnesse.responders.DisabledResponder
+
+!3 Authenticator
+''required property:'' '''!-Authenticator-! = <class name>'''
+
+''motivation:'' Custom security scheme. The class provided must extend the fitnesse.authentication.Authenticator class.  The class will be instantiated and asked ''isAuthenticated(String username, String password)'' when ever authentication is required.  See SecurityDescription for more information on security.
+
+!3 !-Symbol Types-!
+''required property:'' '''!-SymbolTypes-! = <class name>[,<class name]'''
+
+''motivation:'' Custom look-n-feel, or custom functionality hook.
+
+The plug-in class must extend ''!-fitnesse.wikitext.SymbolType-!''. A plug-in class can specify up to four pieces of information for the parser.
+
+The first is a name, specified in the super constructor. The name is just used for error reporting and debugging and so it can be any descriptive string.
+
+The second is the wikiMatcher. This is an object that knows how to identify the symbol type in the source string. The Matcher class provides a lot of common matching behavior, so you can look at the Matcher source to find matching behavior.
+
+The third is the wikiRule, which not all symbol types require. This is an object that implements a grammar production rule if our symbol type is composed of other symbol types (a non-terminal, in grammar-speak). A symbol type that is a terminal doesn't need a production rule. Look at the fitnesse.wikitext.parser package to see examples of how production rule classes are written.
+
+The fourth is the htmlTranslation. This is an object that renders the symbol type as a string in the HTML output. We can implement the Translation interface and specify this as our translation object. The toTarget method renders our output.
+
+Example:
+
+{{{
+public class PiSymbolType extends SymbolType implements Translation {
+    public PiSymbolType () {
+        super("Pi");
+        wikiMatcher(new Matcher().string("!pi"));
+        htmlTranslation(this);
+    }
+
+    public String toTarget(Translator translator, Symbol symbol) {
+        return Double.toString(Math.PI);
+    }
+}
+}}}
+
+!3 !-Content Filter-!
+''required property:'' '''!-ContentFilter-! = <class name>'''
+
+''motivation:'' Restrict the content that is saved on wiki pages. (Damn spammers!)
+
+The classes supplied must extend ''!-fitnesse.responders.editing.ContentFilter-!''.  !-ContentFilter-! is an interface that declares one method:  '''!-boolean isContentAcceptable(String content, String pageName)-!'''.  When ever user attempts to save a page, ''!-isContentAcceptable()-!'' is invoked and the content is saved only if ''true'' is returned.
+
+!3 !-Slim Tables-!
+''required property:'' '''!-SlimTables-! = <table name:class name>[,<table name:class name>]'''
+
+''motivation:'' Allow for custom SLiM table types to be supported.
+
+There may be certain (rare) situations where the default table types are not sufficient. This hook allows for custom SLiM table types. A custom table must extend fitnesse.slimTables.
+
+!3 !-Custom Comparators-!
+''required property:'' '''!-CustomComparators-! = <prefix:class name>[,<prefix:class name>]'''
+
+''motivation:'' The Slim protocol is all String values. It means that comparison of an expected and actual result for complex datatypes is limited to String equality or Regular Expression matching. If that is not sufficient, a Custom Comparator can do more sophisticated comparisons. Once registered, a Custom Comparator is triggered by its prefix, followed by a colon, in front of the expected value.
+
+Example Comparator implementation:
+
+{{{
+public class JSONAssertComparator implements CustomComparator {
+  @Override
+  public boolean matches(String actual, String expected) {
+    try {
+      JSONAssert.assertEquals(expected, actual, false);
+      return true;
+    } catch (JSONException e) {
+      throw new RuntimeException(e.getMessage(), e);
+    }
+  }
+}
+}}}
+
+Example plugins.properties:
+
+{{{
+CustomComparators = json:com.acme.JSONAssertComparator
+}}}
+
+Example !-ScriptTable-! usage:
+
+{{{
+|script|Customer                                 |
+|check |get|cust1|json:{id:cust1,name:"John Doe"}|
+}}}
+
+!3 !-Test Systems-!
+''required property:'' '''!-TestSystems-! = <key:class name>[,<key:class name>]'''
+
+''motivation:'' Allow for custom test systems to be supported.
+
+In case there are situations where you can not get your tests working with the default test systems (Fit and Slim), you have the ability to define custom test systems. Classes should implement the !-fitnesse.testsystems.TestSystemFactory-! interface.
+
+!3 !-Formatters-!
+''required property:'' '''!-Formatters-! = <class name>[,<class name>]'''
+
+''motivation:'' Allow for extra reporting facilities during test execution.
+
+Classes should implement the !-fitnesse.reporting.Formatter-! interface.
+
+!3 !-Plug-ins-!
+''required property:'' '''!-Plugins-! = <class name>[,<class name>]'''
+
+''motivation:'' Register multiple Responders, symbol types, !-WikiPage-! factories, test systems, Slim tables or comparators from a single Java class, instead of multiple entries in plugins.properties.
+
+Please also have a look at the page on WritingPlugins. It provides an alternative (simpler) way to register plugins by using the Java Service loader facility.
+
+Plugins classes can provide one or more of the following methods to register components:
+
+ * '''registerResponders(!-ResponderFactory-! responderFactory)''' - register responders using ''!-ResponderFactory.addResponder(String key, Class responderClass)-!''
+ * '''registerSymbolTypes(!-SymbolProvider-! symbolProvider)''' - register wiki symbol types using ''!-symbolProvider.add(SymbolType symbolType)-!''
+ * '''registerWikiPageFactories(!-WikiPageFactoryRegistry-! wikiPageFactoryRegistry)''' - register page factories used for specific sub pages using ''!-wikiPageFactoryRegistry.registerWikiPageFactory(WikiPageFactory wikiPageFactory)-!''
+ * '''registerTestSystemFactories(!-TestSystemFactoryRegistry-! testSystemFactoryRegistry)''' - register test system factories using ''!-testSystemFactoryRegistry.registerTestSystemFactory(String name, TestSystemFactory testSystemFactory)-!''
+ * '''registerSlimTableFactories(!-SlimTableFactory-! slimTableFactory)''' - register Slim table factories using ''!-slimTableFactory.addTableType(String nameOrPrefix, Class<? extends SlimTable> tableClass)-!''
+ * '''registerCustomComparatorRegistries(!-CustomComparatorRegistry-! customComparatorRegistry)''' - register custom comparators for checks done by the Slim test system using ''!-customComparatorRegistry.addCustomComparator(String prefix, CustomComparator customComparator)-!''
+ * '''registerFormatters(!-FormatterRegistry-! formatterRegistry)''' - register custom formatters using ''!-formatterRegistry.registerFormatter(Class formatterClass)-!''
+
+Plugins are instantiated by FitNesse's !-ComponentFactory-!. By doing so they can support either one of those constructors:
+
+ * Plugin(!-ComponentFactory-! componentFactory)
+ * Plugin(Properties properties)
+ * Plugin()
+
+!1 Other properties
+
+There are more properties which can be used to tweak parts of FitNesse:
+
+ * '''newpage.default.content''' - default page content for an empty page, in case you're not creating a new page based on a template page.
+ * '''VersionsController.days''' - number of days to keep old page versions around when using the Zip file based versions controller.
+ * '''test.history.days''' - The number of days to keep test results around. Cleaned up after a new test run.
+ * '''test.history.path''' - Location to store the test results. The default location is ''!-FitNesseRoot-!/files/testResults''.
+ * Any variable that can be defined on a wiki page.
+
+The Slim test system has a set of [[custom properties][<UserGuide.WritingAcceptanceTests.SliM]] that can either be set on a page or in the configuration file.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/ConfigurationFile/properties.xml

@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<properties>
+<Files/>
+<Help>Configure FitNesse the way you like.</Help>
+<RecentChanges/>
+<WhereUsed/>
+<saveId>1238527780309</saveId>
+<ticketId>-4188313721410542901</ticketId>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/ControllingFitNesseFromTheCommandLine/content.txt

@@ -0,0 +1,71 @@
+!3 Motivations
+
+It is possible to issue single commands to FitNesse from the command line. This is useful when:
+ * Running test suites from your build scripts (see how this is achieved for Ant [[below][#antIntegration]])
+ * Generating XML output from a test execution to a file
+
+!3 Command Syntax
+
+You can run any REST command (See RestfulServices) from the command line by using the -c command line option as follows:
+
+|!style_code(java -jar fitnesse-standalone.jar -c <rest-command>)|
+
+This starts up fitnesse, runs the command, emits the output to standard out, and then exits.
+
+Most often you will use this to run tests and/or suites from the command line as follows:
+
+|!style_code(!-java -jar fitnesse-standalone.jar -c "MyTestPage?test&format=text"-!)|
+
+The ''text'' format causes a simple summary of the tests to be printed to standard output.  It looks like this:{{{
+Starting Test System: slim using fitnesse.slim.SlimService.
+. 07:37:29 R:0    W:0    I:0    E:0    JunkPage (JunkPage) 0.124 seconds
+X 07:37:29 R:0    W:0    I:0    E:3    ExceptionTest    (JunkPage.ExceptionTest) 0.034 seconds
+. 07:37:29 R:0    W:0    I:0    E:0    FirstPage        (JunkPage.FirstPage) 0.329 seconds
+. 07:37:29 R:2    W:0    I:0    E:0    GivWenZen        (JunkPage.GivWenZen) 0.528 seconds
+F 07:37:30 R:6    W:1    I:0    E:0    HashTablePage    (JunkPage.HashTablePage) 0.045 seconds
+F 07:37:30 R:1    W:20   I:0    E:8    CanTotalOrder    (JunkPage.ImportingPage.CanTotalOrder) 0.623 seconds
+X 07:37:30 R:0    W:0    I:0    E:6    JunkPage (JunkPage.JunkPage) 0.083 seconds
+. 07:37:30 R:0    W:0    I:0    E:0    JunkTest (JunkPage.JunkTest) 0.884 seconds
+F 07:37:30 R:1    W:20   I:0    E:8    CanTotalOrder    (JunkPage.PointOfSale.CanTotalOrder) 0.004 seconds
+. 07:37:30 R:0    W:0    I:0    E:0    SeeTest  (JunkPage.SeeTest) 0.765 seconds
+. 07:37:31 R:1    W:0    I:0    E:0    SymbolPage       (JunkPage.SymbolPage) 0.198 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    TestNothing      (JunkPage.TestNothing) 0.923 seconds
+X 07:37:31 R:2    W:0    I:0    E:2    TestTableTable   (JunkPage.TestTableTable) 1.120 seconds
+X 07:37:31 R:0    W:0    I:0    E:4    UseVarPage       (JunkPage.UseVarPage) 0.034 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    VariableTest     (JunkPage.VariableTest) 0.512 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    SuiteSetUp       (JunkPage.ParentSuite.SuiteChildTwo.SuiteSetUp) 0.321 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    TestPage (JunkPage.ParentSuite.SuiteChildTwo.TestPage) 0.432 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    SuiteTearDown    (JunkPage.ParentSuite.SuiteChildTwo.SuiteTearDown) 0.387 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    SuiteSetUp       (JunkPage.ParentSuite.SuiteSetUp) 0.712 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    TestPage (JunkPage.ParentSuite.TestPage) 0.209 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    SuiteTearDown    (JunkPage.ParentSuite.SuiteTearDown) 0.314 seconds
+. 07:37:31 R:0    W:0    I:0    E:0    SuiteSetUp       (JunkPage.ParentSuite.SuiteChildOne.SuiteSetUp) 0.159 seconds
+. 07:37:32 R:0    W:0    I:0    E:0    TestPage (JunkPage.ParentSuite.SuiteChildOne.TestPage) 0.265 seconds
+. 07:37:32 R:0    W:0    I:0    E:0    SuiteTearDown    (JunkPage.ParentSuite.SuiteChildOne.SuiteTearDown) 0.358 seconds
+--------
+24 Tests,       7 Failures.      90.409 seconds.}}}
+Each line begins with . if the test passes, F if the test fails, or X if the test throws an exception.
+The key for the counts is Right, Wrong, Ignored, Exceptions.
+The rest should be self explanatory.
+
+The exit code for the command is 0 unless you run a test with ''text'' formatting, in which case it is the number of failing tests.
+
+!anchor antIntegration
+
+!2 Executing Tests from Ant
+You can run a test suite with Ant using the following ant task {{{
+  <target name="my_fitnesse_tests">
+    <java jar="dist/fitnesse.jar" failonerror="true" fork="true">
+      <arg value="-c"/>
+      <arg value="FitNesse.MySuitePage?suite&amp;format=text"/>
+      <arg value="-p"/>
+      <arg value="9234"/>
+    </java>
+  </target>}}}
+!note !style_green[You only need to set the port if the default command port (9123) will collide with something.]
+
+!2 Running Password-Protected Suites or Tests
+Some work environments which do not allow FitNesse instances without authentication (as the FitNesse tests may access password-protected databases).
+In these cases, the suites and pages will need to be password-protected and authentication must be provided as part of the -c command:
+
+|!style_code(!-java -jar fitnesse.jar -a [user:pwd or user-file-name] -c "username:password:MyTestPage?test&format=text"-!)|