Section 5.1.  Testing Lists Whose Order Is Unimportant

5.1. Testing Lists Whose Order Is Unimportant Here's the business rule for chat room occupants, our first example. A chat room user may ask for a list of all users currently in chat rooms. The list includes the chat room name and the user name. This business rule is related to the one in Section 4.2 on p. 26. A Fit table to test that the current occupants of the chat room are as expected, such as after the actions of Figure 4.6 on p. 27, is shown in Figure 5.1. Figure 5.1. Fit Table for Testing Occupants of a Chat Room OccupantList user room anna lotr luke lotr The first row names the fixture OccupantList, which determines from the system under test the list that is to be tested against the table rows after the second row. In this book, we use the convention that all fixtures related to testing lists include List in their names. The second, header row of the Fit table in Figure 5.1 labels the columns with the two expected[1] field names for the elements of the list. Two further rows are for the two expected occupants of the chat room. The order of these two rows does not need to be the same as their actual order in the system under test. [1] Unlike with ColumnFixture, the labels for expected fields in RowFixture tables usually do not include (). When Fit runs the tests in Figure 5.1, the report shown in Figure 5.2 results, with both rows correct and marked with green. This tells us that two elements are in the collection and that they match the rows given in the table. Figure 5.2. Fit Report for TestOccupants The report in Figure 5.3 (see also Plate 3) results from a different test, in which the expected rows don't match that actual collection. As usual, unexpected values are marked with red. Figure 5.3. Fit Report for TestOccupants Questions & Answers Q1: What happens if there are more occupants than expected? A1: Fit reports the unexpected elements from the actual list as surplus. These elements are added to the bottom of the reported RowFixture table as extra rows. We'll see an example of that shortly. Q2: What if we expect no elements? A2: In that case, the table has no expected rows, as shown in Figure 5.4. The test would fail, with two surplus elements being reported in red, as shown in Figure 5.5 (see also Plate 4). Figure 5.4. Table for Testing That There Are No Occupants OccupantList user room Figure 5.5. Fit Reporting Surplus Occupants
Q3:	What if we want to check the occupants only in a particular room?
A3:	We can do that by providing the room name in the first row, after the fixture name, as shown in Figure 5.6. In general, we can provide one or more values as arguments in the fixture row for any fixture. Figure 5.6. Table for Testing the Occupants of a Selected Room OccupantListInRoom lotr user anna luke
Q4:	Can we make the tests ignore whether the names are uppercase?
A4:	Yes, a programmer can handle that easily in the fixture.
Q5:	What if the order of the occupant rows is important?
A5:	We cover order in the next example.

Programmers

The fixture code for the tests here is given in Section 23.1 on p. 195.