xcfit 0.2.0

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

@@ -0,0 +1,47 @@
+!1 ActionFixture: Testing Sequences of Events
+
+Sometimes the software behavior you are testing is inherently sequential: a series of events occur in a prescribed order. The ActionFixture style of test table (and [[!-FixtureCode-!][<UserGuide.WritingAcceptanceTests.FixtureCode]]) make it easy to write and run tests for such sequences of events. The metaphor for this fixture is a simple control panel:
+ * You ''enter'' values into '''registers''' that have specified names.
+ * You ''press'' '''buttons''' that have specified names.
+ * You ''check'' the values of named '''meters'''.
+
+
+For example, let's write a test for a simple counter.
+
+|Action Fixture.|
+|start|!-fitnesse.fixtures.CountFixture-!|
+|check|counter|0|
+|press|count|
+|check|counter|1|
+|press|count|
+|check|counter|2|
+|enter|counter|5|
+|press|count|
+|check|counter|6|
+
+Many kinds of event sequences can be boiled down to sets of these simple actions: entering, pressing, and checking. This style of table is often used, for example, to check sequences of user interface events.
+
+To see the [[!-FixtureCode-!][<UserGuide.WritingAcceptanceTests.FixtureCode]] for this example, check out ActionFixtureCode.
+
+!2 Seeing How Long ActionFixture Actions Take: !-TimedActionFixture-!
+
+You can used !-TimedActionFixture-! if you want to see visual feedback on how long certain functions take to execute. (Technical note: This is strictly a matter of making sure that the FixtureCode for your table extends !-TimedActionFixture-! instead of ActionFixture.) Here is a version of our counter example that uses !-TimedActionFixture-!:
+
+|!-fit.TimedActionFixture-!|
+|start|!-fitnesse.fixtures.DelayedCountFixture-!|
+|check|counter|0|
+|press|count|
+|check|counter|1|
+|press|count|
+|check|counter|2|
+|enter|counter|5|
+|press|count|
+|check|counter|6|
+
+This !-DelayedCountFixture-! example simply adds a random delay to the ''count'' function.
+
+!-TimedActionFixture-! does not give you a means of testing the time or the ''split''.  It simply displays them for visual inspection. Also note that the TimedActionFixture does not report any delays that are less than one second.  We don't know why Ward (inventor of the [[!-FitFramework-!][<UserGuide.WritingAcceptanceTests.FitFramework]]) decided to impose this lower limit.  Perhaps he'll remove it one day.
+
+!2 Learning More
+To see an example of the fixture code for the ActionFixture test table style, check out ActionFixtureCode. Also check out the other TestTableStyles.
+

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

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

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

@@ -0,0 +1,26 @@
+!1 The Fixture Code for Action Fixtures
+
+Here is our example test table from the ActionFixture page:
+
+|Action Fixture.|
+|start|!-fitnesse.fixtures.CountFixture-!|
+|check|counter|0|
+|press|count|
+|check|counter|1|
+|press|count|
+|check|counter|2|
+|enter|counter|5|
+|press|count|
+|check|counter|6|
+
+And here is the code for the !-CountFixture-!:{{{public class CountFixture extends Fixture {
+  private int counter = 0;
+
+  public void count() {
+    counter++;
+  }
+
+  public int counter() {
+    return counter;
+  }
+} }}}  As you can see, the names of the buttons (''check'', ''press'', and ''enter'') and registers (''count'' and ''counter'') correspond directly to methods in the 'started' fixture. And the meter values (the numbers in the rightmost column) are returned by the ''counter()'' method. It's really as simple as that. 

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

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

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

@@ -0,0 +1,81 @@
+!1 Using !-ColumnFixtures-!
+This table style is probably the most generally useful in FitNesse. Many kinds of software features can be tested with ColumnFixture: any feature that can be expressed as rows of inputs and outputs.
+
+ColumnFixture has the advantages of being easy to design and easy to understand. Below, we show a few more examples of uses for ColumnFixture. For starters, 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 |
+
+The top row of the table provides the name of the ColumnFixtureCode that Fit will use to process the table. The second row specifies the inputs and outputs of the fixture; the column headings ''numerator'' and ''denominator'' specify columns of input values, and the ''quotient?'' heading specifies a column of expected return values. So if we divide 10 by 2, we expect to get back 5.
+
+For a description of the fixture code for the Division example, see ColumnFixtureCode.
+
+!2 A Slightly More Complex Example: A Trivia Game
+Let's imagine that we are building a trivia game. The overall design of our trivia game is straightforward: players take turns rolling a single die, and move around a circular board. When they land on a square, they are asked a trivia question of some category. There are requirements for answering questions incorrectly, for winning, and so on.
+
+For now let's imagine that we are addressing a specific first requirement or user story (call it what you like):
+
+!3 "You can add players to the game, and you can ask the game how many players are playing."
+Sounds pretty straightforward. Let's first set up a [[!-ClassPath-!][<UserGuide.WritingAcceptanceTests.ClassPath]] that points to where our trivia game project is. Without the [[!-ClassPath-!][<UserGuide.WritingAcceptanceTests.ClassPath]], FitNesse would not be able to find our fixture code:
+
+How about this for a test table for this requirement?
+
+!| eg.triviaGameExample.fitnesseFixtures.AddRemovePlayerFixture |
+| playerName | addPlayer? | countPlayers? |
+| Al | true | 1 |
+| Bertha | true | 2 |
+
+It says that if we add a player named Al to our game successfully, the total number of players should be 1, and if we then add a player named Bertha, our total number of players should be 2. If you click Test, you'll see that we have met this requirement. This is well and good, but it will be seldom that we can use a single table to do all the work to test a single requirement. We will typically need to use more than one table.
+
+Say we have another requirement that goes like this:
+
+!3 "Once the game has started, players cannot be added or removed."
+For this test, we'll ask the game to take a fake turn by specifying that the player whose turn it is "rolls" a 6. That should start the game. We'll check the result of that by checking to see which player it was who actually took the turn (we expect it to be Al), and whether indeed the game has started.
+
+!| eg.triviaGameExample.fitnesseFixtures.GameTurnFixture |
+| roll | player? | gameHasStarted? |
+| 6 | Al | true |
+
+Now that the game has started, we'll try to add a new player to the game, and this should fail (we should get back false from addPlayer()). And we should still have only two players in the game:
+
+!| eg.triviaGameExample.fitnesseFixtures.AddRemovePlayerFixture |
+| playerName | addPlayer? | countPlayers? |
+| Joe | false | 2 |
+
+Finally, we'll try to remove a player from the game, and this too should fail:
+
+!| eg.triviaGameExample.fitnesseFixtures.AddRemovePlayerFixture |
+| playerName | removePlayer? | countPlayers? |
+| Al | false | 2 |
+
+This shows how you can use a sequence of tables to verify a requirement by setting up and testing different states in your application code. This table sequence also illustrates one of the common [[!-AcceptanceTestPatterns-!][<UserGuide.WritingAcceptanceTests.AcceptanceTestPatterns]]: [[!-BuildOperateCheck-!][<UserGuide.WritingAcceptanceTests.AcceptanceTestPatterns.BuildOperateCheck]].
+
+For a description of the fixture code for the trivia Game example, see ColumnFixtureCode.
+
+!2 Another Example: an Inventory System
+Let's say you were writing an inventory system, and you wanted to test its ability to keep track of stocked items.  You might write tables like this:
+
+| !-inventory.AddStockFixture-! |
+| partNumber | quantity | valid? |
+| 324 | 28 | true |
+| 586 | 14 | true |
+
+This test adds two stock items.  The valid() method calls the parts of the system that cause a stock item to be added.  Next, we might write a table that simulates some purchases that reduce the stock of an item.
+
+| !-inventory.PurchaseItemFixture-! |
+| partNumber | quantity | valid? |
+| 324 | 3 | true |
+| 586 | 2 | true |
+
+Finally we'd write a table that checked to make sure that the inventory had been properly updated.
+
+| !-inventory.CheckInventoryFixture-! |
+| partNumber | quantity() |
+| 324 | 25 |
+| 586 | 12 |
+
+!2 Learning More
+To learn about the fixture code for the above examples, see ColumnFixtureCode. Check out the other TestTableStyles to see which one suites your purposes best.

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

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

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

@@ -0,0 +1,14 @@
+{{{
+package eg;
+import fit.ColumnFixture;
+
+public class Division extends ColumnFixture {
+  public double numerator;
+  public double denominator;
+  public double quotient() {return numerator/denominator;}
+}
+}}}
+
+Input variables must be public.
+
+If the fixture declares the method ''public void execute()'' it will be called after all fields have been loaded, but before any output methods have been called.

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

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

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

@@ -0,0 +1,43 @@
+!3 Designing Tests with ColumnFixture
+Think of each row of a ColumnFixture as one or more function calls.  The values of the named variables are set, and then the functions are called.
+
+For example, lets say you were writing an inventory system, and you wanted to test its ability to keep track of stocked items.  You might write tables like this:
+
+|!-inventory.AddStockFixture-!|
+|partNumber|quantity|valid?|
+|324|28|true|
+|586|14|true|
+
+This test adds two stock items.  The valid() function calls the parts of the system that cause a stock item to be added.  The code for the !-AddStockFixture-! might look like this:{{{
+package inventory;
+import fit.ColumnFixture;
+public class AddStockFixture extends ColumnFixture {
+  public int partNumber;
+  public int quantity;
+  public boolean valid() {
+    try {
+      StockItem item = new StockItem(partNumber);
+      Inventory.addStockItem(item,quantity);
+      return true;
+    } catch (Exception e) {
+      return false;
+    }
+  }
+}
+}}}Next, we might write a table that simulates some purchases that reduce the stock of an item.
+
+|!-inventory.PurchaseItemFixture-!|
+|partNumber|quantity|valid?|
+|324|3|true|
+|586|2|true|
+
+It should be clear how this fixture would be written.
+
+Finally we'd write a table that checked to make sure that the inventory had been properly updated.
+
+|!-inventory.CheckInventoryFixture-!|
+|partNumber|quantity()|
+|324|25|
+|586|12|
+
+See how easy this is?

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

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

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

@@ -0,0 +1,12 @@
+!1 Using Comment Tables
+Sometimes you just want to explain something using a table. You don't want it to be a test table. But FitNesse presumes all tables are test tables. You need a CommentTable.
+
+You can make comment tables using the ''Comment'' table notation. It's simple. Simply put the word ''Comment'' all alone in the first row of the table, like so:
+
+|Comment|
+|This table is just a comment|
+|and will not participate|
+|in the tests on this page.|
+
+If you click the Test button on a page containing such comment tables, FitNesse and the [[!-FitFramework-!][<UserGuide.WritingAcceptanceTests.FitFramework]] will ignore the comment tables.
+

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

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

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

@@ -0,0 +1,17 @@
+!1 Comparison Expressions in Table Cells
+!note specific to certain FIT implementations.
+
+Comparison expressions can also be used in numeric cells that represent expected outputs.  In these expression the underscore character represents the return value of the method.  You can use standard inequalities.
+ * For example:
+  * '''_ < 32''' or
+  * '''_ >= 99'''.
+ * You can also use a range such as:
+  * '''38 <= _ <55'''.
+ * For simple expressions the underscore can be omitted, thus:
+  * '''<99''' is legal.
+
+There are two special functions that you can override when you write a !-ColumnFixture-!
+ * ''reset()'' will be called at the beginning of each row.
+ * ''execute()'' will be called just prior to processing the first ''()'' or ''?'' cell in each row, or after the last cell in the row has been processed, whichever comes first.
+
+You can use these two functions to treat each row as a transaction.  ''reset()'' can clear all the variables and get ready for the next transaction.  ''execute()'' can do the transaction processing.

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

@@ -0,0 +1,8 @@
+<?xml version="1.0"?>
+<properties>
+	<Files/>
+	<RecentChanges/>
+	<WhereUsed/>
+	<saveId>1238101623822</saveId>
+	<ticketId>5418038042288268028</ticketId>
+</properties>

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

@@ -0,0 +1,21 @@
+You can use all the standard Java data types in RowFixture and ColumnFixture.  These types are automatically translated in and out of cell contents for you.  They include:
+
+ * String
+  * A trimmed string.  You can use the keyword ''null'' or ''blank'' to mean a true java null, or an empty string respectively
+ * byte or Byte
+ * short or Short
+ * int or Integer
+ * long or Long
+ * float or Float
+ * double or Double
+ * char or Character
+ * boolean or Boolean
+  * Will interpret ''true'', ''yes'', ''y'', ''+'', ''1'' to be true.
+  * All else will be false.
+ * Array
+  * Any comma separated list of items will be converted into an array.
+  * Click [[here][.FitNesse.SuiteAcceptanceTests.SuiteFixtureTests.SuiteColumnFixtureSpec.TestArraysInColumnFixture]] to see the acceptance test for this.
+
+!3 Managing your own types with Fit.
+Any user defined type that implements toString and parse will be managed correctly by RowFixture and ColumnFixture.  The signatures of these methods are:{{{String toString();
+static Object parse(String s);}}}

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

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

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

@@ -0,0 +1,2 @@
+Action fixtures give you very simple scripting ability.  Any test that requires a simple set of interactions could be based on an Action Fixture.  For example, you ought to be able to completely test the software that controls a simple dialog box by using the appropriate 'enter', 'press', and 'check' operations.
+

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

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

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

@@ -0,0 +1,4 @@
+The RowFixture implementations that you have seen here have been simplistic, but educational.  In each case the fixture just built up an array of little objects.  In most cases you will build that array up by inspecting your real application data.
+
+However, think about this.  If you have these tests written up front, then you will know what kind of objects they are going to need.  You might be able to create applications that have these objects in them.  Then the fixtures would simply return those objects without having to build them.
+

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

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

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

@@ -0,0 +1,28 @@
+If something goes wrong when you push the ''test'' button, the most likely cause is that you haven't specified the classpath.  Edit the test page and add a !path directive for every classpath that you want included.  See BuildingClassPaths for more information.
+
+Another common problem is a mispelling of the test fixture, or one of the column names.  The symptom is an exception appearing in the table cell that contains the mispelling.
+
+Hit the ''Test'' button to see what these errors look like.
+
+!|eg.thisTestFixtureDoesNotExist|
+|just some data|
+
+!|eg.Division|
+|dividend|divisor|quotient()|
+|5|1|5|
+
+Another odd problem can occurr if the name of the fixture is a WikiWord.  If the corresponding wiki page does not exist, then a ? is appended to it.  Fit sees this ? and thinks it's part of the classname.  Hit the ''Test'' button and then look at the table below.  You should see a ? in the table at the end of the fixture name.  You should also see that ? in the exception report that follows it.  Look closely.
+
+!|somePackage.ClassThatLooksLikeWikiWordButIsntOne|
+|a|b|c|
+
+If you have a problem like this, then what you need to do is surround the name of the fixture in !-!- -! and !- -!-! (see MarkupLiteralText).
+{{{|! -somePackage.ClassThatLooksLikeWikiWordButIsntOne- !|
+|a|b|c|}}}
+Or you can also use the literal tables like this:
+{{{!|somePackage.ClassThatLooksLikeWikiWordButIsntOne|
+|a|b|c|}}}
+'''Tip for viewing exceptions in small font'''
+If you have a scroll-wheel mouse, hold the ctrl key and scroll the wheel. It increases/decreases the font size quickly in most browsers.
+
+

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

@@ -0,0 +1,8 @@
+<?xml version="1.0"?>
+<properties>
+	<Files/>
+	<RecentChanges>true</RecentChanges>
+	<WhereUsed/>
+	<saveId>1238103061084</saveId>
+	<ticketId>5671685757323426249</ticketId>
+</properties>

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

@@ -0,0 +1,16 @@
+ * ''INTEGER'' : A integer value in the form of a 10 byte string
+  * !-0000000000 = 0-!
+  * !-0000000005 = 5-!
+  * !-0000000123 = 123-!
+ * ''READ'' : Reading a value involves two step.
+  1 read an ''INTEGER'' value, n
+  2 read n bytes.
+ * ''WRITE'' : Writing a value involves two steps
+  1 count the bytes in value and write the size as an ''INTEGER''
+  2 write the value as bytes
+ * ''WRITE COUNTS'' : Write the counts as 4 ''INTEGER''s
+  1 right
+  2 wrong
+  3 ignores
+  4 exceptions
+ * ''STATUS'' : Length of Error Message. If it is zero, the connection has been established. If not, it is followed by the Error Message.

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

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

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

@@ -0,0 +1,4 @@
+A program that is required for each implementation of FIT that couples FIT to FitNesse.
+
+FitServer is executed by FitNesse and will communicate through a socket with FitNesse.  The protocol used is described in FitServerProtocol.
+