xcfit 0.9.0 → 1.0.0

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

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<Help>Some pages in FitNesse that serve special purposes.</Help>
-<RecentChanges/>
-<Search/>
-<Static/>
-<WhereUsed/>
-<saveId>1238171723779</saveId>
-<ticketId>5784148408046429312</ticketId>
-</properties>

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

@@ -1,24 +0,0 @@
-Every time you run a test or a suite, the results are recorded in the ''test history database''.  You can view the history by clicking on the !style_code(Test History) button.  The reports are pretty self-explanatory.
-
-When you click on !style_code(Test History) you will be shown the directory of all tests and suites that are in thie ''test history database''.  This directory also shows you the status of the last 20 results from each test or suite.  You can click on the name of the test or suite to get a detailed ''page history'', or you can click on any of the individual status elements to see the particular test result.
-
-The detailed ''page history'' shows you a directory of all the test results for that test or suite.  The bar chart shows how how the number of tests (for suites) or assertions (for tests) has grown over time, and the pass/fail ratio.  Clicking on an entry takes you to that specific test result.
-
-!4 Details
-The ''test history database'' is kept in !style_code(!-FitNesseRoot/files/testResults-!).  Beneath this directory there is a subdirectory for each test or suite.  These directories contain the ''page history'' and are named for the page that contains the test or suite.  Beneath the page history directory is a file for each test result.
-
-The test result files are named using the following scheme !style_code(YYYYMMDDHHMMSS_R_W_I_E.xml)  where YYYYMMDDHHMMSS is the date and time of the test run, and R, W, I, and E are integers representing the number of Right, Wrong, Ignored, and Exception counts for the test or suite.  For tests they are assertion counts.  For suites they are test counts.  (Example: !style_code(20090513134259_12_20_4_2.xml))
-
-The test files contain the XML that describes the test run.  The format of this XML is identical to the XML packet returned by the format=xml flag when you run a test.  (See <UserGuide.RestfulTests).
-
-!4 Purging
-There are buttons at the top of the ''Test History'' page that allow you to purge old history files.  You have your choice of ''all'', ''>7 days'', or ''>30 days''.  If you want to purge a different number of days, you can use the RESTful URL form.  (See [[!-RestfulServices-!][<UserGuide.AdministeringFitNesse.RestfulServices]]).
-
-You can also clean up the test history right after a test execution. To do so, configure a property ''test.history.days'' in the [[configuration file][<UserGuide.AdministeringFitNesse.ConfigurationFile]] or as a [[page variable][<UserGuide.FitNesseWiki.MarkupLanguageReference.MarkupVariables]] and assign it the number of days you want to keep history.
-
-!4 Comparing History
-When viewing the history for a page, you can select any two test results by clicking in their checkboxes.  Then, if you click the ''Compare'' button, you will be shown the two test results side-by-side along with an indicator that tells you if the results are identical or not.
-
-Only tests can be compared this way.  Suites cannot.
-
-Notice that the comparison is pretty smart.  It tries to line up the two tests on a table-by-table basis.  It can detect if tables have been inserted or deleted.  The % code that you see on the left is just the match score for the tables.

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

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/CrossReferenceSuites/content.txt

@@ -1,11 +0,0 @@
-!3 Suite Cross References
-Sometimes you want to compose a test suite from test pages that are in many different modules, subsystems, or features.  For example you might want a test suite that lists all the test pages for the current iteration, or you might want a test suite that lists all the currently passing tests, or you may want to create a test suite for all the quickly executing tests, and another for all the slow tests.
-
-To do this you can use the [['''!-!see-!'''][<UserGuide.FitNesseWiki.MarkupLanguageReference.MarkupCrossReference]] command in a test suite.  Any test pages referenced by '''!-!see-!''' on a suite page will be executed as part of that suite.
-
-The suite page might look like this:
-{{{
-!see .MyProject.MyFeature.IterationOne.StoryOne.TestCaseOne
-!see .MyProject.MyFeature.IterationTwo.StoryTwelve.TestCaseThirteen
-...
-}}}

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/CrossReferenceSuites/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/SubWikiSuites/content.txt

@@ -1,22 +0,0 @@
-!3 [[!-SubWiki-!][<FitNesse.FullReferenceGuide.UserGuide.FitNesseWiki.SubWiki]]: the Most Convenient Way to Organize [[!-TestSuites-!][<FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.TestSuites]]
-
-[[!-SubWikis-!][<FitNesse.FullReferenceGuide.UserGuide.FitNesseWiki.SubWiki]] are convenient for creating a hierarchical structure for your suite of tests.  You can put test pages below subsystems and/or features.  You can organize [[!-ClassPath-!][<FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.ClassPath]] and variable definitions in the parent pages.  When you hit the ''Suite'' button on a parent page, all the descendant pages that have the ''Test'' property will be executed as part of the suite.  FitNesse's own set of acceptance tests is organized this way.  See <FitNesse.SuiteAcceptanceTests.
-
-You can use the hierarchy to organize your test by Iteration, or by Feature, or by any other scheme you like.  The acceptance tests for FitNesse are organized by feature.  Other teams organize by iteration.  A typical hierarchy by iteration might look like this:
-
-{{{
-MyProject
-  IterationOne
-    StoryOne
-      TestCaseOne
-      TestCaseTwo
-      ...
-    StoryTwo
-      TestCaseOne
-      TestCaseTwo
-      ...
-    ...
-  ...
-}}}
-Of course you'd use better names than that.  You could then mark the project, iteration, and story pages as suites.  If you hit the suite button on the project page it would execute every test in the project.  If you hit the suite button on MyProject.IterationOne.StoryTwo it would execute only those tests in the second story of the first iteration.
-

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/SubWikiSuites/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/SuiteQuery/content.txt

@@ -1,22 +0,0 @@
-A Suite Query is a regular page with the ''Suite'' property set so that it has a ''Suite'' button.  On that page are one or more tables that specify the query.  The page you are looking at right now, is a suite query.  Notice the two tables below.  They specify the query.  You can run the query (and the tests) by hitting the ''Suite'' button.
-
-!|Suite|
-|Page|FitNesse.SuiteAcceptanceTests|
-|Content|[Bb]ug|
-
-!|Suite|
-|Page|FitNesse.SuiteAcceptanceTests|
-|Title|Import|
-
-Each of these tables is called a ''Suite Specification''.  A ''Suite Specification'' is always a table whose first cell is the word ''Suite'', capitalized as shown.  The other rows must each have two cells, and the first cell in each row must be either ''Page'', ''Content'' or ''Title''.  
- * ''Page'' - The second cell in the ''Page'' row is the fully qualified page name that forms the root of the search.  The search will proceed only with descendants of this page.
- * ''Title'' - The second cell in the ''Title'' row specifies a regular expression to be used to match a page name. Every page in the search whose name matches that regular expression will be included in the suite.
- * ''Content'' - The second cell in the ''Content'' row specifies a regular expression to be used to match the contents of a page.  Every page in the search whose content contains a string that matches that regular expression will be included in the suite.
-
-Every ''Suite Specification'' table represents the ''Intersection'' of the ''Page'', ''Title'', and ''Content''.  Thus, they form an ''AND'' operation.  Only those pages that are descended from ''Page'' and match ''Title'' and match ''Content'' will be in the suite.  Of course, if either ''Title'' or ''Content'' are omitted (as above) then they are ignored.  
-
-If you have multiple ''Suite Specification'' tables, then the suite will be the ''disjuction'' (The logical OR) of all of them.  
-
-!note The regular expressions conform to the Java library. 
-
-

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/SuiteQuery/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/SuiteSetUpAndSuiteTearDown/content.txt

@@ -1,6 +0,0 @@
-!3 !-SetUp-! and !-TearDown-!
-Sometimes you will need to delete a test database at the end of each test in a suite, or create an empty database at the beginning of each test.  Operations like this can be performed by writing special fixtures that perform these functions in their constructors.  These fixtures can then be invoked in the '''!-SetUp-!''' and '''!-TearDown-!''' pages of the suite.  See <FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.SpecialPages.
-
-To perform operations at the beginning or end of an entire suite, rather than for each test, define the operations on pages named '''!-SuiteSetUp-!''' and '''!-SuiteTearDown-!'''.
-
-!-SuiteSetUp and SuiteTearDown-! are associated with a test page by "Uncle Inheritance" as described in <FitNesse.FullReferenceGuide.UserGuide.WritingAcceptanceTests.SpecialPages.  A suite has many different test pages, and it is possible that some will have different !-SuiteSetUp and SuiteTearDown-! pages.  Therefore tests in a suite are organized into groups that share the same !-SuiteSetup and SuiteTearDown-! pages.  The tests are executed in those groups, with the !-SuiteSetUp-! preceding them, and the !-SuiteTearDown-! following them.   

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/SuiteSetUpAndSuiteTearDown/properties.xml

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

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/TagsAndFilters/content.txt

@@ -1,33 +0,0 @@
-!3 Suite Tags
-
-The properties page offers a field labeled ''Tags'' where you can enter a comma-separated list of keywords. These keywords can then be used as targets for searching and executing those tests.
-
-!3 Searching for tags
-If you hit the !style_code(Search) button, You will see a form that allows you to search for pages that certain attributes or tags.  For example, you can search for all subpages that have the !style_code(Suite) property set, or all pages that are read-only, or that have the !style_code(Edit) button displayed.  Most importantly, you can search for pages marked with tags.
-
-If you put a comma separated list of tags into the !style_code(Tags) input box, and then search, you will be shows a list of pages that are marked with any of those tags.  Notice that if the pages are tests or suites, they have a link next to them that allows you to execute them.   Also, look at the bottom and see the useful text that can be copied and pasted onto other pages in order to repeat the search or test the resulting pages.
-
-Using these tools, you can easily tag some tests as "smoke" tests, or "critical", or "fast".  You can find all the "smoke" tests and run them, etc.
-
-!3 Using tags to select which tests to run.
-The easiest way to execute tagged tests is to search for the tags as described in the previous section.  Sometimes, though, you'd like to execute the tests via a RESTful service, or from the command line (see [[!-ControllingFitNesseFromTheCommandLine-!][<FitNesse.FullReferenceGuide.UserGuide.AdministeringFitNesse.ControllingFitNesseFromTheCommandLine]]).
-You can execute the tests that match a tag (or comma separated list of tags) by using the !style_code(runTestsMatchingAnyTag) query parameter with a suite url like this:
-!style_code(!-http://&lt;host>:&lt;port>/&lt;suite path and test name>?responder=suite&runTestsMatchingAnyTag=smoke,critical-!)
-
-''This parameter used to be !style_code(suiteFilter).  Both versions are supported and both versions run a test if any one tag matches for a page.''
-
-It is also possible to run test that match all of the tags in your filter.  This is done with the !style_code(runTestsMatchingAllTags) parameter, like so:
-!style_code(!-http://&lt;host>:&lt;port>/&lt;suite path and test name>?responder=suite&runTestsMatchingAllTags=smoke,critical-!)
-
-If you want to execute all the tests in a suite except those with a particular tag (eg !-NotRunningOnHudson-!) then you use the !style_code(excludeSuiteFilter) query parameter:  For example:
-!style_code(!-http://&lt;host>:&lt;port>/&lt;suite path and test name>?responder=suite&excludeSuiteFilter=NotRunningOnHudson-!)
-
-''There is no AND type behavior on excludeSuiteFilter.  Any test that matches any of the listed tags will be skipped.''
-
-Typically, you will need only a few of such filtered suites, so it is suggested to build a link on the front page or so which contains the respective suite filter parameters. (If you simply click on the ''Suites'' button to run a suite, the !-suiteFilter-! is not set, so all tests in the respective subwiki are run.)
-
-!3 Executing test starting with a certain test.
-Sometimes half the suite will run okay, but after a point all tests will start failing.   In that case you can save time re-running the tests by stating which test you would like to start with.   For instance:
-!style_code(!-http://&lt;host>:&lt;port>/&lt;suite path and test name>?responder=suite&startTest=TestTwo-!) will run all tests coming after !-TestTwo-!
-
-Remember, that the order tests run is alphabetical.  So in the above example, !-TestThree-! will not run because !-TestTwo-! actually comes after !-TestThree-!

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/TestSuites/TagsAndFilters/properties.xml

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

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

@@ -1,13 +0,0 @@
-!1 Suites of Tests
-A suite is a collection of test pages that can all be run together, and whose results are then collected for you on a single results page, and in TestHistory. For an example of a Suite of tests, see .FitNesse.SuiteAcceptanceTests.
-
-!3 Setting up a '''Suite''' page.
-To create a Suite page you set the "Suite" property of that page (see [[Page Properties][<UserGuide.FitNesseWiki.PageProperties]]).  That page will then include a "Suite" button that will execute all the test pages in that hierarchy.
-
-!3 Composing Suites.
-There are several ways to compose a suite.  You can convert a whole sub-wiki into a suite.  You can list individual pages using cross references, and you can create queries that search all the pages for matches.
-
-!contents -R2 -g
-
-!3 Getting suite results in XML rather than HTML format.
-If you want the results in xml, simply put !style_code(&format=xml) in the url.

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

@@ -1,10 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<Normal/>
-<RecentChanges/>
-<Static/>
-<WhereUsed/>
-<saveId>1238174950604</saveId>
-<ticketId>-8493028553090165617</ticketId>
-</properties>

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

@@ -1,7 +0,0 @@
-!1 FitNesse Test Systems.
-!img http://files/fitnesse/images/fitnesse_architecture.jpg
-This diagram shows how !-FitNesse-! works with the two Test Systems, [[Slim][SliM]], and [[Fit][FitFramework]].
-
-[[FIT][FitFramework]] is the older of the two, and uses HTML.  The HTML parsing is done on the SUT just prior to the fixtures being called.  This means that there is a lot of code on the SUT.  Over the years many different ports of FIT have been attempted, but because FIT is large, and because programmers always have better ideas the second and third time they implement something, the various FIT ports are quite inconsistent.  This means that tests written on one platform won't work on another.
-
-[[Slim][SliM]] is newer.  As the diagram shows, there is very little code on the SUT.  This is because all the table processing is done inside FitNesse, within the Slim runners.  The Slim Executor and the fixtures are the only code that lives on the SUT.  The Slim Executor is very small and easy to port.  The Test pages are broken down into simple instructions by the Slim Runners.  Those instructions are passed to the Slim Executor which directs the fixtures to call the SUT.  This means that new features added to Slim Runners will not require changes on the Slim Executor, and that all test pages written for a Slim Runner will work on any different Slim platform.

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

@@ -1,14 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Edit/>
-<Files/>
-<Properties/>
-<RecentChanges/>
-<Refactor/>
-<Search/>
-<Static/>
-<Versions/>
-<WhereUsed/>
-<saveId>1238175009151</saveId>
-<ticketId>-6940628553317529561</ticketId>
-</properties>

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

@@ -1,7 +0,0 @@
-Variable are in scope if they are defined on the page in question or in somewhere in the parent hierarchy of the page in question.
-
-For example, lets say the variable we are interested in is X.
-
- * If X is defined on this page then it is definately in scope.
- * If X is not defined on this page but is defined in the page .FitNesse (this page's parent), then X is still in scope.
- * If X is defined on .FitNesse.UserGuide.FitNesseWiki then X is not in scope because .FitNesse.UserGuide.FitNesseWiki is not a parent of this page.

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

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

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

@@ -1,93 +0,0 @@
-In this section you can read about the >TestSystems FitNesse provides out-of-the-box:
- * [[Fit][>FitFramework]] 
- * [[Slim][>SliM]]
-
-Organize tests:
- * >TestSuites
- * >SpecialPages
- * >TestHistory
- * >AcceptanceTestPatterns
-
-Implement the tests:
- * >FixtureCode
- * >ClassPath
- * >VariableScope
-
-Running tests:
- * >RunningAcceptanceTests
- * >RunningFromJunit
- * >RunningFromMaven
- * >CustomizingTestExecution
-
-If it does not work directly:
- * >AttentionMessagesInTestResults
- * >DebuggingFitNesseTables
- * >DebuggingFixtureCode
-
-Odds and ends:
- * >RestfulTests
-
-Pages can be marked as [[''Test'' pages][<UserGuide.FitNesseWiki.PageProperties]]. Those pages can be executes by a >TestSystems. In this section you'll learn about creating test tables, linking those to your application code and receiving feedback from you >TestSuites.
-
-Each page that has tests will consist of a series of HTML tables. Fitnesse understands various formats of tables, and if those formats are not sufficient, developers are welcome to add additional ones. Generally, the tables take the basic form of a Command cell and some Parameter cells, which are followed by some Output cells. When a test is run, the command and parameters are evaluated to see if the correct output is given. [[The Two minute example][<UserGuide.TwoMinuteExample]] should get you started.
-
-!3 Creating the Table
-Okay, so you saw what FitNesse can do. You ran a test with some inputs, checked to make sure the outputs were as expected, and saw how easy it was to determine whether the application worked correctly or not. Now you'd like to create some tests of your own. How do you do it? If you go back and edit the [[Example page][<UserGuide.TwoMinuteExample]], you'll see some wiki markup that 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. Go ahead and modify this page a little. Add some extra rows with some additional numbers to test, or change some of the numbers around. Then save the page, and click the Test button. You'll see how the system is set up to show successes and failures ''each time you run the test''. This ability to modify a test and immediately see the result is a big benefit of having integration tests.
-
-!1 Getting Test Tables Onto the Page
-As we have seen FitNesse expresses WritingAcceptanceTests as tables of '''input''' data and '''expected output''' data. (If you have not done so, you should probably check out the example table tutorial in the [[Two minute example][<UserGuide.TwoMinuteExample]]. You should then check out the wiki page-editing tutorial on [[editing FitNesse pages][<UserGuide.FitNesseWiki.EditingFitNessePages]].) Yet again, let's look at our test table for testing the division function of a calculator application:
-
-!| eg.Division |
-| numerator | denominator | quotient? |
-| 10 | 2 | 5 |
-| 12.6 | 3 | 4.2 |
-| 100 | 4 | 33 |
-
-So how do we get this table on to the page? Well the [[wiki markup language][<UserGuide.FitNesseWiki.MarkupLanguageReference]] that defines the above table looks like this:{{{
-|eg.Division|
-|numerator|denominator|quotient?|
-|10       |2          |5        |
-|12.6     |3          |4.2      |
-|100      |4          |33       |  }}}
-
-!3 Typing it In By Hand
-We can pretty easily type in the above markup code for our Division table by hand in the page editing window. The vertical bars (!-|-!) delimit cells within rows. As long as you have the right number of vertical bars between data elements, FitNesse will correctly format your table for you. For small tables that will not change frequently, that's a perfectly reasonable way to do it.
-
-!3 Using a Spreadsheet to Create Tables
-Let's face it: a simple text-editing frame (such as the FitNesse edit frame) is not the best tool in the world for manipulating tabular representations of data. It's not especially easy to copy and paste rows or columns, move rows or columns, etc. That's the sort of thing that spreadsheets are great at. When you work with lots of FitNesse tables, particularly large ones, it's great to be able to work in a spreadsheet like Excel to get the table just the way you want it, then copy it over to FitNesse, formatted properly using the wiki markup language. Fortunately, FitNesse makes this easy to do.
-
-!3 Spreadsheet Example
-Let's say that you have the ''Division'' table in Excel and you want to move it into FitNesse.
-
- * Within Excel, select the table and copy it to the clipboard.
- * Go to the FitNesse page where you want the table and ''Edit'' it (or create it).
- * Paste the table into the edit pane. It will show up without any wiki markup formatting:
-
-{{{
-eg.Division
-numerator        denominator        quotient?
-10        2        5
-12.6        3        4.2
-100        4        33 }}}
-
- * Now click the '''!-Spreadsheet to FitNesse-!''' button on the bottom of the page.
-
-''Voila!'' FitNesse reformats the table (and any other table on the page) with the proper wiki markup delimiters:{{{
-!|eg.Division|
-|numerator|denominator|quotient?|
-|10|2|5|
-|12.6|3|4.2|
-|100|4|33| }}}
-
-'''Note: This is best done one table at a time''', one page at a time. Furthermore, the table must have '''at least two columns'''. When you click the '''!-Spreadsheet to FitNesse-!''' button, FitNesse attempts to format everything on the page that '''might''' be a table.
-
-!3 Copying Tables From FitNesse to the Spreadsheet
-You can also take an existing FitNesse table, select it, and click the '''!-FitNesse to Spreadsheet-!''' button to get it back into non-wiki markup language format. You can then easily paste it back into the spreadsheet application.
-
-!2 Learning More
-If you are interested in the fixture code that makes it possible to run test tables, check out >FixtureCode. If you want to learn what the different styles of test tables are and how to apply them, check out >TestSystems and their table types.

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

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

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

@@ -1,43 +0,0 @@
-!***< variables
-
-!define REGRACE_LINK {true}
-*!
-!1 !c FitNesse User Guide
-!c Robert C. Martin,
-!c Micah D. Martin,
-!c Patrick Wilson-Welsh &
-!c FitNesse contributors
-----
-!3 Table of Contents
- * [[Introduction][#introduction]]
- * [[Working with the FitNesse wiki][>FitNesseWiki]]
- * [[Writing Acceptance Tests][>WritingAcceptanceTests]] (jump directly to [[Fit][>WritingAcceptanceTests.FitFramework]] or [[Slim][>WritingAcceptanceTests.SliM]])
- * [[Administering FitNesse][>AdministeringFitNesse]]
- * [[Quick Reference Guide][>QuickReferenceGuide]]
- * [[Full Reference Guide][<FitNesse.FullReferenceGuide]] (takes some time to load)
-
-!1 Introduction !anchor introduction
-
-FitNesse is a tool for specifying and verifying application acceptance criteria (requirements). It acts as a bridge between the different stakeholders (disciplines) in a software delivery process. It's wiki server makes it easy to document the software.It's testexecution capabilities allow you to verify the documentation against the software, ensuring the documentation remains up to date and the software is not facing regression.
-
-For this to work, the tests should be defined on a business level, in conjunction with business representatives. They are basically business requirements, laid out in a way easy to understand by all stakeholders. When your requirements are unambiguous, they can be automatically verified with your application.
-
-To make it easy for all stakeholders to interact with FitNesse, requirements can be created and edited through the web browser. It's a wiki! By writing specifications (also known as [[Acceptance Tests][>AcceptanceTests]]), you can create a common understanding among the team (coders and non-coders). This helps tremendously in [[delivering the right system][>DeliveringTheRightSystem]]. Specifications can be written in wiki syntax or in a rich text editor, so no knowledge of the wiki syntax is required.
-
-Because the specifications can actually be executed, FitNesse provides a method to demonstrate even to non-coders that the application works as designed. This can prevent problems leading to [[Project Death by Requirements][>ProjectDeathByRequirements]]. The goal is for FitNesse to operate at a level just ''below'' the user interface level, demonstrating that, given various inputs to your application, the correct results are computed. In a sense, you could consider it an alternative user interface for the application.
-
-Convinced? Have a more in-depth look at how FitNesse works in our [[Two Minute Example][>TwoMinuteExample]]. [[Download and install][http://fitnesse.org/FitNesseDownload]] FitNesse on your machine, if you haven't done so already. Then learn how to [[work with the FitNesse wiki][>FitNesseWiki]] and [[write Acceptance Tests][>WritingAcceptanceTests]].
-
-!3 Brief history
-FitNesse started as an HTML and [[wiki][http://wiki.org/wiki.cgi?WhatIsWiki]] "front-end" to [[FIT][http://fit.c2.com/]] ("Framework for Integrated Testing") back in 2001.
-
-!*** From the [[Fit website][http://fit.c2.com/]]:
-
-Great software requires collaboration and communication.Fitis a tool for enhancing collaboration in software development. It's an invaluable way to collaborate on complicated problems -and get them right- early in development.
-
-Fit allows customers, testers, and programmers to learn what their software ''should'' do and what it ''does'' do. It automatically compares customers' expectations to actual results.
-
-*!
-Interestingly both the wiki and Fit were developed by Ward Cunningham, and you can read about them both on Ward's [[c2 wiki][http://fit.c2.com/]].
-
-Nowadays FitNesse is a comprehensive tool, supports multiple test systems and has been used for many software and even hardware projects.

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

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

data/XCFitDemo/FitNesseRoot/FitNesse/content.txt

@@ -1,6 +0,0 @@
-!1 FitNesse
-
-Below this page you can find all the content provided as part of the FitNesse distribution.
-
-!contents -g
-!path lib/*.jar

data/XCFitDemo/FitNesseRoot/FitNesse/properties.xml

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