Table Fixture Example and Acceptance Test

This is the example TableFixture from page 82 of the FIT book. The example table is used several times in succession. The first usage is to create the invoice object, the other examples show different ways of checking the invoice table against the invoice object.

All of the examples should pass; they were created by cut and paste of the first table, with a different fixture name.

Create Test Data

This first table creates the invoice with two line items, and saves it in the symbol table under the name "invoice1", using the parameter facility. The other fixtures will get the symbol which references the invoice from the first parameter

This first table also illustrates a significant issue with all of the creation fixtures: There is no guidance about how to annotate that edits were made and passed, and that the resulting data was successfully saved for later use. Each of the fixtures that does this does it differently. In this case, I've chosen to highlight each cell that was actually accessed and checked, even if the check was as simplistic as blindly accepting a character string.

In addition, there is no standard way of indicating that the entire edit was successful and the result created and stored. I've chosen to indicate this by highlighting the symbol name which is the cell immediately after the fixture name. This could probably be enhanced by adding a comment, such as "invoice saved" or "invoice checked".

fit.AccTestFixtures.TableFixtureAT.StoreTable invoice1
Uni of AucklandDelivered To:Number:216017-01
Private Bag 92019Attn: Sal MayhaDate:05/01/04
AucklandUni of AucklandOrder:TC000015473-REPL
 Cust:UNI34
#Part NumberDescription DispatchPriceTotal
1CAT 98142-00-GHL3 Switch 32x1000T 16804.006804.00
2CAT 99000-01-PHMacronetic Switch 22317.002317.00
 Total:9121.00
Special Delivery:AS0555P

Verify table without using TypeAdapter

This is the more normal use of a TableFixture, to verify an object created by the actual processing part of the test.

The essential distinction between this and the next one is in the fixture. This one does not use the TypeAdapter mechanism, which means that it cannot use the cell handlers, including either the asis[] cell handler or the error or exception[] handlers

fit.AccTestFixtures.TableFixtureAT.CheckTable1 invoice1
Uni of AucklandDelivered To:Number:216017-01
Private Bag 92019Attn: Sal MayhaDate:05/01/04
AucklandUni of AucklandOrder:TC000015473-REPL
 Cust:UNI34
#Part NumberDescription DispatchPriceTotal
1CAT 98142-00-GHL3 Switch 32x1000T 16804.006804.00
2CAT 99000-01-PHMacronetic Switch 22317.002317.00
 Total:9121.00
Special Delivery:AS0555P

Check Table using Type Adapters

The only difference between this and the preceeding check is the fixture invoked. When you look at the two fixtures, you'll see that using the type adapter mechanism simplifies the checking logic, but doesn't do anything significant for the mainline.

fit.AccTestFixtures.TableFixtureAT.CheckTableUsingTA invoice1
Uni of AucklandDelivered To:Number:216017-01
Private Bag 92019Attn: Sal MayhaDate:05/01/04
AucklandUni of AucklandOrder:TC000015473-REPL
 Cust:UNI34
#Part NumberDescription DispatchPriceTotal
1CAT 98142-00-GHL3 Switch 32x1000T 16804.006804.00
2CAT 99000-01-PHMacronetic Switch 22317.002317.00
 Total:9121.00
Special Delivery:AS0555P

That's the TableFixture example. I've deliberately kept away from most of the advanced features in this example, other than the use of the parameter and symbol facility to pass data among fixtures.