28.5. Actions on Domain Objects with DoFixtureConsider now the test from Section 10.3 on p. 75, shown again in Figure 28.5. The action in the first row of the second table selects a User, with the actions in the rest of the table being applied to that User. Figure 28.5. TestUserAs we see in the extended fixture class in Listing 28.5, the method connect() carries out the connection action and then returns a UserFixture to interpret the rest of the table. The class UserFixture is a DoFixture, as shown in Listing 28.6. It has methods corresponding to the two actions in the second and third rows of the second table in Figure 28.5. The room action in the first row of the third table of Figure 28.5 selects a room. The method room() in ChatStart is called, which creates a new DoFixture with the Room as argument. The two action rows that follow call through that new DoFixture to the underlying Room object. In general, if a method call for an action returns an Object, which is not a Collection, Iterator, or an array, DoFixture automatically creates a new DoFixture with it and returns that. Hence, the method room() can be removed from ChatStart. Then the method room() in the ChatRoom, the system under test, will be called instead. This returns an object of class Room, which is automatically wrapped with another DoFixture, and that is returned to interpret the rest of the table. The final, slimmed-down ChatStart class for all these tests is shown in Listing 28.7. Listing 28.5. ChatStart.java (version 3)
Listing 28.6. UserFixture.java
Listing 28.7. ChatStart.java (version 4)
|
Friday, December 4, 2009
Section 28.5. Actions on Domain Objects with DoFixture
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment