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 <UserGuide.ColumnFixture that has the equivalent of a valid() function. The rows in the table load and save data, and the 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 <UserGuide.ColumnFixture and has always had the equivalent of a valid() function. The columns specify the arguments of the operation and the 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 <UserGuide.ColumnFixture or <UserGuide.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 Bill Wake discovered that he calls "Arrange, Act, Assert," (as you might find in the xUnit style of unit testing tools: JUnit for Java, or NUnit 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.

Examples:

Test Bread Crumbs	Classic BOC fitnesse test for showing that FitNesse deals properly with bold widgets.
Add And Pay Test	BOC fitnesse test for making sure paychecks are being generated properly. This test uses two Check tables.