Tuesday, December 22, 2009

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.












    No comments: