Section 10.1. Flow-Style Actions with DoFixture


10.1. Flow-Style Actions with DoFixture

An alternative approach to writing tests for sequences of actions is to use a flow style in which we start with a DoFixture table. For example, the test reported in Figure 10.1 checks that on disconnecting, a user is no longer an occupant of a room. The fixture ChatStart is named in the first table. As this is a DoFixture table, it is the only one that needs a fixture name.

Figure 10.1. TestDisconnect


In the tables in Figure 10.1, the following sequence of steps is carried out.

  1. The chat server, the system under test, is started.

  2. A user connects to the chat server.

  3. That user creates a room.

  4. The user enters that room.

  5. We check the single occupant in the lotr room.

  6. The user disconnects.

  7. We check that the room is empty.

The names of the actions used in a table are chosen by the table writer to be clear about what is happening in the test.

Following are several differences between using flow style for action tests and ActionFixture tables.

  • Only the first table in a flow-style sequence needs to have a fixture name, which is a DoFixture.

  • In flow style, the name of an action, such as connect user, is made up by the test writer.

  • A flow-style action is defined in a single row. For example, consider the second table of Figure 10.1. Instead of entering a name before pressing connect, as with an ActionFixture, we use a single action row, connect user, that includes the user name. This makes it easy to read the flow of the test, especially if actions have several data values.

  • A flow-style action contains keywords in the first cell and in every second cell of the row thereafter. The keywords are shown in italics in Figure 10.1 and are colored green in the report; they may contain any characters. Such keywords allow us to be explicit about the role of the data values in the other cells. For example, the action row in the third table of Figure 10.1 includes the keywords user, creates, and room, which have been chosen to be clear about the role and order of the data values in the other cells of the action.

  • Actions may be provided in separate tables but need not be. For example, the actions in tables 2, 3, and 4 of Figure 10.1 could be included together in a single table.

  • Where a particular action may succeed or fail, DoFixture automatically marks the action accordingly in green or red in the report. All the actions in Figure 10.1 are of this form, except for the one in the last table. This avoids the need to explicitly check that an action has succeeded, making the test more succinct.

  • A check action in flow style is applied to another action rather than to a single field, as with ActionFixture. For example, the last table in Figure 10.1 checks that the occupant count of the specified room is 0empty.

  • Instead of using a fixture name, an action in a flow-style table may select a particular fixture, determining how the rest of that table is to be used in testing. For example, in the fifth table, the action in the first row selects a RowFixture that is used to check the following rows against the occupants in the lotr room.

Programmers

The fixture code for the tests here is given in Section 28.1 on p. 227.


Questions & Answers

Q1:

Some action rows have a keyword in the last cell. Is that optional?

A1:

Yes, if it makes it easier to read the action, you can place a keyword at the end. It's also possible to have empty keyword cells, where no word is needed for readability; we'll see examples of such actions in Chapter 14.

Q2:

Can the core fixtures, such as ColumnFixture, be used with DoFixture?

A2:

Yes, in two ways. In flow style, any table after the first can contain a fixture name. That table is handled in the normal way, as described in previous chapters. Subsequent tables are still in flow style.

Also, an action in a DoFixture table can select any fixture, which is used to test the rest of that table. In Figure 10.1, this occurs in the fifth table where a RowFixture checks the users in the specified room.

Q3:

Can a DoFixture table be used after core fixture tables?

A3:

Yes, but an explicit fixture name is needed in the first row of the table. Subsequent tables are not in flow style.

Q4:

How do we know whether it's a DoFixture or a ColumnFixture table?

A4:

With a little experience, you can usually tell what type of table it is by the structure or contents of the rows and/or tables that follow or by understanding what the test is trying to do. Otherwise, you may need to ask the person who wrote the test or ask a programmer to find out by looking at the fixture code.

ColumnFixture and RowFixture tables have a regular structure, with rows of the same length and containing similar values. You can often tell that it's a ColumnFixture table by the header row, with one or more labels having () or ? after the name.

ActionFixture tables usually start with the fit.ActionFixture fixture. The rows that follow are of different lengths and contain the enter, press, and check actions.

DoFixture table rows vary in length and contain specific actions with names that should clarify what's going on in the test. Generally, several small tables are used in a sequence, sometimes with only one row in a table.



    Fit for Developing Software. Framework for Integrated Tests
    Fit for Developing Software: Framework for Integrated Tests
    ISBN: 0321269349
    EAN: 2147483647
    Year: 2005
    Pages: 331

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net