xcfit 0.2.0

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

@@ -0,0 +1,13 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<properties>
+<Edit/>
+<Files/>
+<Normal/>
+<Properties/>
+<RecentChanges/>
+<Refactor/>
+<Versions/>
+<WhereUsed/>
+<saveId>1237228032275</saveId>
+<ticketId>-5542215261053372341</ticketId>
+</properties>

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

@@ -0,0 +1,99 @@
+!***< Hidden
+
+!define TEST_SYSTEM {slim}
+*!
+!1 An Example !-FitNesse-! Test
+If you were testing the division function of a calculator application, you might like to see some examples working. You might want to see what you get back if you ask it to divide 10 by 2. (You might be hoping for a 5!)
+
+In !-FitNesse-!, tests are expressed as tables of '''input''' data and '''expected output''' data. Here is one way to specify a few division tests in !-FitNesse-!:
+
+|eg.Division                    |
+|numerator|denominator|quotient?|
+|10       |2          |5.0      |
+|12.6     |3          |4.2      |
+|22       |7          |~=3.14   |
+|9        |3          |<5       |
+|11       |2          |4<_<6    |
+|100      |4          |33       |
+
+This style of !-FitNesse-! test table is called a [[Decision Table][<UserGuide.WritingAcceptanceTests.SliM.DecisionTable]], each row represents a complete scenario of example inputs and outputs. Here, the "numerator" and "denominator" columns are for inputs, and the question mark in the "quotient?" column tells !-FitNesse-! that this is our column of expected outputs. Notice our "10/2 = 5.0" scenario. Try reading it as a question: ''"If I give you a numerator of 10 and denominator of 2, do I get back a 5?"''
+
+!3 Running our test table: Click the Test button
+If you are reading this page on a local copy of !-FitNesse-!, run this test table. See the '''Test''' button in the upper-right corner? Click it and see what happens.
+
+!*** Now, if you're reading this on the web site, ...
+
+... you probably found that the FitNesse Test button in that example didn't work as advertised. It's been disabled on purpose to minimize stress on the site. But that's ok - since among other things, FitNesse is a wiki, you can simply download and run it, and read these same web pages as served up by your local system. When you do that, you'll be able to run the tests. Why not [[download it now][http://fitnesse.org/FitNesseDownload]]?
+
+*!
+Ah, color! In the green cells, we got back the expected values from our code. When we divided 10 by 2, we expected and got back 5. When we divided 12.6 by 3, we expected and got back 4.2.
+
+What about red? A cell turns red when we get back a different value than what we expected. We also see two values: the '''expected''' value and the '''actual''' value. Above we expected 33 back when we divided 100 by 4, but we got back 25. Ah, a flaw in our test table. That happens!
+
+Notice also the comparisons.  22/7 is approximately equal (~=) to 3.14.  9/3 is less than 5.  11/2 is between 4 and 6.
+
+!3 Creating the Table
+How did we put that test table on this page in the first place? Well, we used !-FitNesse-! itself to do it!
+
+!-FitNesse-! is a [[wiki][http://wiki.org/wiki.cgi?WhatIsWiki]], which is a style of web server that allows any visitor to make any edits, including changing existing pages and creating new pages. A simple markup language lets you easily create headings, make text bold, underline, and italic, create bulleted lists, and do other kinds of simple formatting. You can read more about it on [[Editing FitNesse Pages][<UserGuide.FitNesseWiki.EditingFitNessePages]].
+
+Once you download !-FitNesse-! to your own computer, you can edit any page simply by clicking on the Edit button on the left (just below the Test button). If you are reading this page on your own copy of !-FitNesse-! on your own machine, you can click the Edit button and see for yourself.
+
+The wiki markup for our table above (with some omissions) looks like this:{{{|eg.Division|
+|numerator|denominator|quotient?|
+|10       |2          |5        |
+|12.6     |3          |4.2      |
+|100      |4          |33       |}}}The vertical bars delimit table cells. For this table, there is not much more too it than that. You don't have to line up the vertical bars this way; we just do it to make it easier to read.
+
+Note that if you don't like mucking about with a markup language at all, you can create your test tables in a spreadsheet such as Excel, copy them to the clipboard, and use the '''Spreadsheet to Fitnesse''' button on the Edit page to have FitNesse format your table properly for you.
+
+'''Note''' also that if you change "eg.Division" to any other name, you may need to use a ! before the fixture to avoid confusing FitNesse with [[!-WikiWord-!][<FitNesse.FullReferenceGuide.UserGuide.FitNesseWiki.WikiWord]]s (see [[Markup Table][<FitNesse.FullReferenceGuide.UserGuide.FitNesseWiki.MarkupLanguageReference.MarkupTable]])
+
+!3 Fixture Code
+What '''really''' happens when we click that test button? (Try clicking it again.) What gets run?
+
+ * First, FitNesse submits the test table to [[Slim][<UserGuide.WritingAcceptanceTests.SliM]], the underlying test system (a test system contains the code required to actually perform the tests).
+ * Slim looks for and runs the fixture code corresponding to the test table.
+ * By design, the fixture code calls some underlying application code to do the real work, and report results back to the fixture
+ * Fit gives Fitnesse back the results from running the fixture code
+ * FitNesse figures out whether to turn table cells red or green (or yellow, if an exception was thrown) and displays the results page accordingly
+
+!3 What is Fixture Code?
+The fixture is the Java (or some other supported language) class that Slim will use to process the contents of the table. In the top row of the table above, "eg" specifies a Java package (or other language namespace), and "Division" specifies the actual class to be called.
+
+Here is what the Java version of the Division class might look like:{{{
+public class Division {
+  private double numerator, denominator;
+  
+  public void setNumerator(double numerator) {
+    this.numerator = numerator;
+  }
+  
+  public void setDenominator(double denominator) {
+    this.denominator = denominator;
+  }
+  
+  public double quotient() {
+    return numerator/denominator;
+  }
+} }}}
+
+!3 How Slim Uses Fixture Code to Process the Test Table
+The Division table is an example of a [[Decision Table][<UserGuide.WritingAcceptanceTests.SliM.DecisionTable]]; just one of many different kinds of tables. Slim processes the rows of example data ('''from left to right'''), it stores the values from the ''numerator'' and ''denominator'' columns in the corresponding fields in our Division class using the setter functions. For each row, it then calls the quotient() method on our Division class, which returns what we would expect it to: the numerator divided by the denominator. So the Decision Table directs Slim to call setNumerator(10) and setDenominator(2); and then to call quotient().  The value is returned to the Decision Table which colors the appropriate cell.
+
+Click the Test button again and see what happens to the column of expected outputs under the ''quotient?'' header. For each cell of expected output, the Decision Table compares the value it expects to get back with what it actually gets. If the return value matches the value in the corresponding table cell, FitNesse turns the cell green. Otherwise FitNesse turns the cell red, and shows both the expected and actual values. (If Slim encounters an exception, or cannot find a fixture, field, or method, it turns the corresponding table cell yellow, and inserts a stack trace.)
+
+!3 Wait a Minute. That's ''Too'' Simple.
+How right you are. In the real world, the fixture code would not be doing any of the real work (though a single division operation is not much work). The fixture code would delegate to real application code, which in turn would do the work. In general, fixture code should be '''as thin as possible'''. It should be nothing but '''piping and wiring''' between the FitNesse table and the application code under test.
+
+So with that bit of wisdom in our minds, you can have a look at [[something a bit more realistic][<UserGuide.WritingAcceptanceTests.FixtureCode]].
+
+!3 Learning More
+!4 More Technical Detail...
+If you are more interested in learning how to create the code that makes test tables work, see [[Fixture Code][<FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.FixtureCode]]. If you want to start diving into installing and running FitNesse, check out [[fitnesse.org][http://fitnesse.org/FitNesseDownload]].
+
+!4 More Usage Detail...
+If you are more interested in why and how to get teams to use FitNesse, see AcceptanceTests.  If you want to learn how to create and run FitNesse tests, check out [[Editing FitNesse Pages][<FitNesse.FullReferenceGuide.UserGuide.FitNesseWiki.EditingFitNessePages]], [[Creating Test Tables][<FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests]], and [[Test Table Styles][<FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.SliM]].
+
+!4 Or Take Your Own Path
+Finally, if you want to zoom back out and look at all of the FitNesse topics, check out the table of contents on the <UserGuide.

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

@@ -0,0 +1,15 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<properties>
+<Edit/>
+<Files/>
+<Help>A brief example.</Help>
+<Properties/>
+<RecentChanges/>
+<Refactor/>
+<Search/>
+<Test/>
+<Versions/>
+<WhereUsed/>
+<saveId>1238092849129</saveId>
+<ticketId>-8522914120834285308</ticketId>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/BuildOperateCheck/content.txt

@@ -0,0 +1,10 @@
+This pattern shows up repeatedly in FitNesse Acceptance Tests. You need to use several tables on a single page, in order to fully test a given requirement. These tables naturally fall into three categories:
+
+ 1 '''Build''': One or more tables to ''Build'' the test data.  These tables are typically based upon a [[!-ColumnFixture-!][<UserGuide.WritingAcceptanceTests.FitFramework.ColumnFixture]] that has the equivalent of a !style_code[valid()] function.  The rows in the table load and save data, and the !style_code[valid()] function returns a boolean indicating whether the data was valid and properly saved.
+ 2 '''Operate''': A table to operate on the data.  This table is typically based upon a [[!-ColumnFixture-!][<UserGuide.WritingAcceptanceTests.FitFramework.ColumnFixture]] and has always had the equivalent of a !style_code[valid()] function.  The columns specify the arguments of the operation and the !style_code[valid()] function performs the operation and return a boolean to indicate success.
+ 3 '''Check''': One or more tables to validate the operation.  These fixtures might be of the style [[!-ColumnFixture-!][<UserGuide.WritingAcceptanceTests.FitFramework.ColumnFixture]] or [[!-RowFixture-!][<UserGuide.WritingAcceptanceTests.FitFramework.RowFixture]].  It is in these tables that the real acceptance tests are performed.  The other two tables just set up conditions for the '''Check''' operation.
+
+'''Note''': This pattern is quite similar to the automated [[unit testing pattern][http://weblogs.java.net/pub/wlg/854]] Bill Wake discovered that he calls "'''Arrange, Act, Assert'''," (as you might find in the [[xUnit][http://encyclopedia.thefreedictionary.com/XUnit]] style of unit testing tools:  [[JUnit][http://www.junit.org]] for Java, or [[NUnit][http://www.nunit.org]] for C#). There may be no semantic difference. The syntactic difference is that in unit tests, you can typically express all of your arranging, acting, and asserting as a few lines of code in a single test method. In FitNesse you need a page containing several tables to express all of your building, operating, and checking.
+
+!3 Examples:
+|[[Test Bread Crumbs][<FitNesse.SuiteAcceptanceTests.SuiteWikiPageResponderTests.TestBreadCrumbs]]|''Classic BOC fitnesse test for showing that FitNesse deals properly with bold widgets.''|

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/BuildOperateCheck/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/CommonIncludes/content.txt

@@ -0,0 +1,11 @@
+It is very common to have a many tests that look alike.  In most cases these test will have duplicate content perhaps to setup the environment for the test.  This duplication can very very painful when the environment changes.  The change to the enviroment will have to be made in all the tests that share the duplicated content.  This can very tedious and time consuming work.  Fortunately it can be avoided.
+
+Using the [[Include widget][<UserGuide.FitNesseWiki.MarkupLanguageReference.MarkupPageInclude]] is the key.  Let's assume that our tests follow the standard [[BOC][BuildOperateCheck]] pattern and they look like this:
+
+!include SampleSetupForTest
+
+!include SampleOperateForTest
+
+And now we'll perform the Check step.
+
+!|A table that checks something|

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/CommonIncludes/properties.xml

@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<properties>
+<Files/>
+<RecentChanges>true</RecentChanges>
+<WhereUsed/>
+<saveId>1130158434501</saveId>
+<ticketId>5401049948558438943</ticketId>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/ParameterizedIncludes/content.txt

@@ -0,0 +1,16 @@
+When using the CommonIncludes pattern you may come across duplicated content that varies with only one or two values.  This can make using includes difficult but when combined with variables, includes become even more powerful.  You can parameterize included pages by declaring variables in the test page and referencing them in the included page.
+
+First we'll include a parameterized include page without defining any variables.
+!include SampleParameterizedPage
+
+Now we define the required variables.
+!define NUMERATOR {100}
+!define DENOMINATOR {10}
+!define QUOTIENT {10}
+!include SampleParameterizedPage
+
+We can redefine the variables and use the parameterized include again.
+!define NUMERATOR {555}
+!define DENOMINATOR {5}
+!define QUOTIENT {111}
+!include SampleParameterizedPage

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/ParameterizedIncludes/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/SampleOperateForTest/content.txt

@@ -0,0 +1,5 @@
+This is the Opertation step of our sample test.
+
+It is common among multiple tests so it is saved in a separate page that can be included by test pages.
+
+!|A table the performs an operation that needs checking|

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/SampleOperateForTest/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/SampleParameterizedPage/content.txt

@@ -0,0 +1,8 @@
+This page requires that 3 variables be defined before it is included.
+ * NUMERATOR
+ * DENOMINATOR
+ * QUOTIENT
+
+!|eg.Division|
+|numerator|denominator|quotient?|
+|${NUMERATOR}|${DENOMINATOR}|${QUOTIENT}|

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/SampleParameterizedPage/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/SampleSetupForTest/content.txt

@@ -0,0 +1,5 @@
+This is the Build step of our sample test.
+
+It is common among multiple tests so it is saved in a separate page that can be included by test pages.
+
+!|A table that sets up for a test|

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/SampleSetupForTest/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/content.txt

@@ -0,0 +1,8 @@
+!1 !c Acceptance Test Patterns.
+There seem to be patterns associated with writing acceptance tests with Fit and FitNesse.
+
+| >BuildOperateCheck | ''Three tables for each test.'' |
+| >CommonIncludes | ''Avoid duplicate test content by creating pages that are included into tests.'' |
+| >ParameterizedIncludes | ''Using variables and Includes together to achieve function-like behavior.'' |
+| >StaticBeforeDynamic | ''First check the end results, then check the in-process results.'' |
+| >OperateFunction | ''Column Fixtures often need a special function to perform an operation between input and output.'' |

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AcceptanceTestPatterns/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AttentionMessagesInTestResults/content.txt

@@ -0,0 +1,20 @@
+You'll occasionally see a big ATTENTION message in your tests.  This typically means that something went wrong with the test and either Fit or Fitnesse had to bail out.  If you click on the link inside the message you'll be taken to a page that will show you everything we know about what went wrong, including any standard error output from any of your fixtures.
+
+The execution log information is stored alongside the test history. So you will not get it if you execute your tests with the ''?noHistory'' option enabled. 
+
+This page is ''always'' created whenever you run a test, not just when there are errors.  So even if you don't get the big ATTENTION message, you can still go to the appropriate execution log page to see things like the command that was used to run your test, and the time it took to run the test, etc.
+
+You can access the execution log of previous runs by going to the Test- or Page history. There you can select the output of a specific run. This page will contain a link to the appropriate execution log information. Note that most information (such as the command used to start the test/suite) is only saved once as part of the execution log of the initiating page.
+
+An !-execution log-! page typically looks like this:
+
+| '''Date: ''' | !-6:49:19 PM (CST) on Thursday, February 26, 2004-! |
+| '''Command: ''' | !-java -cp fitnesse.jar;classes fit.FitServer-! |
+| '''Exit code: ''' | !-0-! |
+| '''Time elapsed: ''' | !-0.28 seconds-! |
+
+----
+{{{ This is an error
+}}}
+
+!2

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/AttentionMessagesInTestResults/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/ClassPath/content.txt

@@ -0,0 +1,22 @@
+!1 The !-ClassPath-!: Telling FitNesse Where the FixtureCode Is
+
+For a given [[Sub Wiki][<UserGuide.FitNesseWiki.SubWiki]] of test pages, you can specify to FitNesse where it can find all of the fixture classes it needs by supplying a so-called ClassPath definition, which is a full absolute filepath to the directory that contains the package (in Java) or assembly (in C#) in which all the compiled classes can be found.  Simply include a ClassPath definition on the main page of your [[Sub Wiki][<UserGuide.FitNesseWiki.SubWiki]].
+
+
+The wiki markup widget you use is the !-!path-! widget. The format, in wiki markup language, looks like this:
+
+{{{!path   C:\workspace\TriviaGameFitNesseExample\}}}
+
+And on a page, the same definition looks like this:
+
+!path C:\workspace\TriviaGameFitNesseExample\
+
+!3 How Fit Locates ClassPath Definitions in !-SubWikis-!
+Whenever Fit processes test tables on a given page, it build its own internal class path by finding the !path directives on the current page, and on every ancestor page.  In other words, it looks '''up''' the page hierarchy of [[!-SubWikis-!][<UserGuide.FitNesseWiki.SubWiki]].
+
+This makes it possible for you to use !path directives on sub pages to override !path directives on parent pages. Thus you can create global classpaths, project specific classpaths, and even module-specific classpaths.
+
+!2 Learning More
+If you are interested in FitNesse fixture code in general, check out FixtureCode. For information on organizing test pages into hierarchies, see [[Sub Wiki][<UserGuide.FitNesseWiki.SubWiki]] and TestSuites.
+
+

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/ClassPath/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/CustomizingTestExecution/content.txt

@@ -0,0 +1,37 @@
+You may customize the way tests are executed to suit your needs. You can even change the language of execution!
+The is done by defining any of a few special variables in the scope (see VariableScope) of the tests you wish to execute.
+The special variables are:
+
+ * TEST_SYSTEM
+ * COMMAND_PATTERN
+ * TEST_RUNNER
+ * PATH_SEPARATOR
+ * REMOTE_DEBUG_COMMAND
+ * REMOTE_DEBUG_RUNNER
+ * CLASSPATH_PROPERTY
+
+'''TEST_SYSTEM''' Defines the interface that FitNesse will use to execute tests.  Right now there are two such interfaces: {fit | slim}
+''default: '' '''<undefined>''' which implies fit.
+
+'''COMMAND_PATTERN''' is the basis for every execution performed in FitNesse.  It specifies the command that will be executed.
+''default: '' '''java -cp %p %m'''
+There are two special symbols used that will get replaced before execution.
+ * '''%p''' will be replaces with the calculated path/classpath.  This is the accumulation of all the ''!path'' elements on all the ''ClassPath'' pages in the scope of the current page.
+ * '''%m''' stands for '''main''' or '''main class'''.  For Java it is the name of the class that will be executed.
+
+'''TEST_RUNNER''' is the name of the class or executable that will be used when the ''Test'' button is clicked.
+''default: '' '''!-fit.FitServer-!'''
+If you're running tests in Java you probably don't want to change this.
+
+'''PATH_SEPARATOR''' is the charater that is used to separate all the path elements in the calculated path.
+''default: '' '''system dependant.... either ; or :'''
+
+'''REMOTE_DEBUG_COMMAND''' is the command pattern used to execute tests in debug mode.  See DebugingFixtureCode for more details.
+''default:'' Same as command pattern, except if contains "java" then '''"java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 -cp %p %m"''' is used instead
+It has the same format as the standand '''COMMAND_PATTERN'''
+
+'''REMOTE_DEBUG_RUNNER''' is the test runner used to execute tests in debug mode.  See DebugingFixtureCode for more details.
+''default:'' Same as TEST_RUNNER, except substring "runner.exe" is replaced by '''"runnerw.exe"'''
+It has the same format as the standand '''TEST_RUNNER'''
+
+'''CLASSPATH_PROPERTY''' specifies the name of the environment variable into which the classpath (gathered from !path statements) will be placed before running the test.  This is most commonly used when the size of the classpath is too large for certain inept operating systems to deal with.  Instead of specifying the %p argument of the COMMAND_PATTERN, you can instead !style_code[!-!define CLASSPATH_PROPERTY {CLASSPATH}-!].  This is most useful for Java.  For other languages it may not have much meaning.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/CustomizingTestExecution/properties.xml

@@ -0,0 +1,15 @@
+<?xml version="1.0"?>
+<properties>
+	<Edit/>
+	<Files/>
+	<Help/>
+	<Normal/>
+	<Properties/>
+	<RecentChanges/>
+	<Refactor/>
+	<Suites/>
+	<Versions/>
+	<WhereUsed/>
+	<saveId>1224243062251</saveId>
+	<ticketId>-2035431799417459728</ticketId>
+</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/DebuggingFitNesseTables/content.txt

@@ -0,0 +1,21 @@
+So, you'd like to debug your fixtures?  Remember that fixtures are run in a ''completely'' different process from FitNesse  It's not easy to set a breakpoint in a fixture and then hope to trap there when the fixture is going to be run in a different process.  But don't worry too much.  If your fixture is written in java, then you can use !style_code(&debug), otherwose you can still use print statements.
+
+!4 &debug
+When you hit the test button it runs the test by issuing the URL !style_code(!-http://myHost:myPort/MyPage?test-!).  You can force the execution to take place in the same JVM that FitNesse is running in by modifying that url to !style_code(!-http://myHost:myPort/MyPage?test&debug-!).  If you have connected your debugger to fitnesse, then you should be able to set breakpoints in your fixtures.  Of course this will only work if the fixtures are written in Java.
+
+!4 Print Statements
+Anything you print to standard out, or standard ''error'' will be placed in the execution log for your test run.  This is true whether the test fails or succeeds.  The execution log is created whenever you run a test. After a test or suite has been executed, a button "Execution Log" appears. Log information of previous runs is available through the Page History.
+
+Debugging your fixtures should be something you rarely need to do.  After all, the code in your fixtures shouldn't be doing very much.  At most it should be simply wiring and piping to get the data from your tables into your application and back.
+
+An execution log page looks like this:
+-----
+|'''Date: '''        |!-6:49:19 PM (CST) on Thursday, February 26, 2004-!|
+|'''Command: '''     |!-java -cp fitnesse.jar;classes fit.FitServer-!    |
+|'''Exit code: '''   |!-0-!                                              |
+|'''Time elapsed: '''|!-0.28 seconds-!                                   |
+----'''Standard Error:'''
+{{{ This is an error
+}}}
+-----
+Notice that you can see the command that was used to run your test.  This is very useful if you are concerned that your fixtures aren't running with the right classpaths.  You can see the classpaths sent to the test in the ''-cp'' argument of the ''java'' command.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/DebuggingFitNesseTables/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/DebuggingFixtureCode/content.txt

@@ -0,0 +1,29 @@
+!2 Debugging with a local wiki site
+
+To debug fixture execution when wiki pages are accessible over a local file system, see RunningFromJunit.
+
+Debugging is also possible with the ''FitNesse'' language plugin for !-IntelliJ-! IDEA.
+ 
+!2 Debugging with a remote wiki site
+
+Fixture code of a remote FitNesse wiki site can be debugged using the remote debugger to connect to the slim executor or fit client.
+
+To set up debugging for your fixture code:
+ 1 If necessary (it should work out of the box for java and C# slim), set up the '''REMOTE_DEBUG_COMMAND''' and '''REMOTE_DEBUG_RUNNER''' in your wiki.  Together these commands should start the server in debug mode and wait for the debugger to connect before the code is run.  As these variales are only used when you start a test in debug mode it is a good idea to specify this define on root page of your wiki.
+ 2 When you want to debug a test, start by adding '''?responder=test&remote_debug=true''' to the url for the test.
+ 3 After starting the test in FitNesse, start a remote debugging process in your debugging tool which should connect to slim/fit server.  Remember to make sure you are using the right port.  (Port 8000 if you are using the default settings for java)
+
+The Tools menu contains a Remote Debug action that can be used to start a test run in debug mode.
+
+Alternatively, just drag the following link to the bookmark toolbar of your favourite browser: !-<a title="Debug FitNesse" id="debugfitnesse" href="javascript:(function(){var url = document.location.pathname + '?responder=test&remote_debug=true'; window.location = url;})();"><span>Debug FitNesse</span></a>-! (since the link contains javascript, this may not work for all browsers).
+
+!2 Alternative way to debug when using Slim
+For.NET it was found to be easier to debug starting the slim runner with the debugger attached and then getting fitnesse to connect to this started instance.  
+
+To do it this way:
+1. Make sure !define MANUALLY_START_TEST_RUNNER_ON_DEBUG=true is set on the page you want to debug running
+2. Start the runner, on the default slim port.   To find out what this is try ${SLIM_PORT} on your page. 
+3. Start fitnesse.   It should automatically connect to the runner you started. 
+
+One thing to note is that when fitnesse finishes the page it will automatically close down the runner.   So you will need to start the slim runner each time you go to debug. 
+

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/DebuggingFixtureCode/properties.xml

@@ -0,0 +1,11 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<properties>
+<Edit>true</Edit>
+<Files>true</Files>
+<Properties>true</Properties>
+<RecentChanges>true</RecentChanges>
+<Refactor>true</Refactor>
+<Search>true</Search>
+<Versions>true</Versions>
+<WhereUsed>true</WhereUsed>
+</properties>