We have explored the use of RowFixture for testing lists, both ordered and unordered.
A fixture for a table of type RowFixture is a fit.RowFixture subclass that provides the actual list of elements from the system under test, along with the class of those elements.
RowFixture compares the expected and actual elements and reports on those expected elements that partially match, those that are missing from the actual list, and those elements that are surplus, or not expected.
The actual list may need to be assembled from objects from the system under test.
Questions & Answers
Q1:
What would happen if the future value of the first row of Figure 23.3 were changed from low to slow?
A1:
When it attempts to match that row against an actual element, RowFixture starts from the leftmost column and works to the right. Because that futureValue doesn't match any element, the row is treated as "missing." The corresponding actual element is then marked as "surplus" in the report.
Q2:
Why can't the element type be worked out automatically by the fixture?
A2:
It could be, although there may not be a common superclass of all those objects. But a fixture like RowFixture could process each of the elements individually.
Q3:
What if the elements don't share a superclass?
A3:
In that case, the actual common superclass is Object, which has no instance variables. One approach would be to use separate tables, each with its own fixture; each fixture would have to filter out the elements of the right class to assemble a suitable array for the table concerned.
Another approach is for a fixture to handle the differences between objects in the actual collection and expect that a cell is empty if there is no corresponding instance variable. This approach is taken with ArrayFixture and related FitLibrary fixtures, as we see in Section 28.9 on p. 243.