This pattern shows up repeatedly in FitNesse AcceptanceTests: 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 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 ColumnFixture and has always had the equivalent of a valid() function. The columns specify the arguments of the operation. The valid() function performs the operation and returns a boolean to indicate success.
3. Check: One or more tables to check the results of the operation. These fixtures might be of the style ColumnFixture or RowFixture. It is in these tables that the real acceptance tests are performed. The preceding tables just set up conditions for the Check tables.

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 Bold Text	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.