Section 4.2. Actions on a Chat Server

4.2. Actions on a Chat Server

The business rule for changes to a chat server, our second example of ActionFixture, follows.

A chat user connects, creates a new chat room, and enters it. Another user connects and enters the same room. Check that the room has two occupants.

A simple table for testing this is shown in Figure 4.6. The second row of the table starts ChatServerActions, starting the application under test. In this book, fixtures that test actions have Action in their names.

Figure 4.6. Fit Table for Testing a Chat Server

fit.ActionFixture
start	ChatServerActions
enter	user	anna
press	connect
enter	room	lotr
press	new room
press	enter room
enter	user	luke
press	connect
press	enter room
check	occupant count	2

The third row, and those that follow, carry out the following action sequence:

1. enter a user name of anna

2. press the connect button to connect user anna to the chat server

3. enter a room name of lotr

4. press the new room button for anna to create a new room named lotr on the chat server

5. press the enter room button for anna to enter lotr, the new chat room

6. enter a user name of luke

7. press the connect button to connect user luke to the chat server

8. press the enter room button for luke to enter the lotr room

9. check that the occupant count for the lotr room is 2

After all actions have been carried out, the device model for this is as shown in Figure 4.7. The resulting Fit report is shown in Figure 4.8.

Figure 4.7. Device After All Actions

Figure 4.8. Fit Report for TestChatServer

Note

In deciding on concrete examples and working out how to express them in tables, we use and invent terminolgy for discussing important things in the business domain. Domain-Driven Design [Eva04] shows how this language is formed through a dialogue among the various stakeholders about what is required of a software system.

Questions & Answers

Q1:	Can comments be put in the tables?
A1:	Yes, it is valuable to include discussion with the tables. We'll first see the use of such documentation in Chapter 6, when we look at sequences of tables.
Q2:	Why tables?
A2:	That's an interesting question. Tables provide just enough structure and no more, helping to organize information, including tests. As we'll see in the next chapter, Fit associates tables with tests and ignores all other information when running those tests. Written requirements are rarely structured enough to permit automated testing. In addition, rows and cells of a table can be colored and have extra information added in a Fit report, giving feedback in the same form as the tests.

Programmers

The fixture code for the tests here is given in Section 22.2 on p. 190.