Section 6.1. Chat Room Changes

6.1. Chat Room Changes

We'll use a variant of the chat room examples from Section 4.2 on p. 26 and Section 5.1 on p. 31. The example here will illustrate a sequence of ActionFixture and RowFixture tables that test changes to a chat server, the system under test. The test sequence, reported in Figure 6.1, consists of six tables, as follows.

1. The first, ActionFixture table starts the system under test.

2. The second table, also an ActionFixture, connects the user anna, who creates a new chat room, lotr, and enters it. Note that this table has no start action because the system under test has already been started, in the first table.

3. The third table, also an ActionFixture, connects the user luke, who enters lotr, the current room.

4. The fourth is a RowFixture table that tests that there are two occupants of lotr, the only room.

5. The fifth is another ActionFixture table that disconnects the user anna.

6. The sixth is another RowFixture table that tests that there is one occupant left in the lotr room.

Figure 6.1. TestTwoInLotr Report

Note

The test writer and programmers need a shared agreement about what each table means, so that a programmer can write the fixture accordingly. As we'll see in Chapter 11, the table may be structured specifically to enable tests to be expressed clearly; this may require the programmer to create a new type of fixture to ensure that the tests may be run automatically against the system under test.

We'll see in Part II that tests often evolve from a collaborative effort of businesspeople, testers, and programmers.

The textual comments between the tables reported in Figure 6.1 are helpful in explaining the steps in the test, as well as the overall intent of the test. Images, lists, and other information may also be included to aid comprehension and communication. These are all ignored by Fit, which simply interprets the tables as containing tests.

Tip

The first three tables in Figure 6.1 could have been combined into a single table. Instead, we have used three tables in order to separate and organize the actions of the two users.

We'll see a similar use of separate tables to organize tests in the next section as well.

Another, related, test sequence is reported in Figure 6.2. The fifth table tests that there are no occupants of any rooms, and so it has no expected rows. This table is unusual in that it passes, but no green is reported.

Figure 6.2. TestConnectAndDisconnect

The sixth table in Figure 6.2 is a fit.Summary table, which reports various test statistics about the previous tables in the test. The table does this by adding cells to the table; Figure 6.3 shows how the table is written in the original test.

fit.Summary

Programmers

The fixture code for the tests here is given in Section 24.1 on p. 203.