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: enter a user name of anna press the connect button to connect user anna to the chat server enter a room name of lotr press the new room button for anna to create a new room named lotr on the chat server press the enter room button for anna to enter lotr, the new chat room enter a user name of luke press the connect button to connect user luke to the chat server press the enter room button for luke to enter the lotr room 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.