Section 4.1. Buying Items

4.1. Buying Items

Here's the business rule for the first example of an ActionFixture table.

A user selects a number of items to buy. The total price is accumulated for those items.

Figure 4.1 shows a simple table for testing. The first row is the fixture name, as usual: in this case, ActionFixture. The second row of the table starts BuyActions. This starts the application under test, which will accumulate the total price.

Figure 4.1. Fit Table for Testing Buying Items

fit.ActionFixture
start	BuyActions
check	total	00.00
enter	price	12.00
press	buy
check	total	12.00
enter	price	100.00
press	buy
check	total	112.00

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

1. check that the total is initially 00.00

2. enter a price of 12.00

3. press the buy button to buy an (unspecified) item of price 12.00

4. check that the total is now 12.00, as expected

5. enter a second price of 100.00

6. press the buy button to buy an item of price 100.00

7. check that the total is now 112.00, as expected

The actions in the rows of the table are carried out in the order given. The columns of the table as a whole serve only to split up each of the rows into cells.

The resulting report is shown in Figure 4.2. Only the check results are marked, with the green showing that the total value was as expected each time.

Figure 4.2. Fit Report for TestLineItems

Underlying this ActionFixture is a device model; it's not a real device and is not intended to be testing through the user interface. We can imagine that after the start, the device model is like that shown in Figure 4.3 for TestLineItems. The device model is made up of:

1. An input field for entering the price

2. A buy button to press

3. A display for checking the total

Figure 4.3. Initial Device

The device shown in Figure 4.4 is after the first six actions in Figure 4.1, just before the buy button is pressed.

Figure 4.4. Device After Five Actions

Questions & Answers

Q1:

The seventh row changes the price in Figure 4.1 to 100.00. What happens if that row is removed?

A1:

Because the price has not been changed to 100.00, another 12.00 will be added to the total, resulting in the check in the last row being wrong (24.00 instead of 112.00).

Q2:

Do you mean that we should test through the user interface?

A2:

No, we don't mean to imply that; the terminology of ActionFixture simply uses a device interface as a metaphor.

It's best to avoid testing through the user interface, as that is difficult and leads to tests that break when the user interface changes. We'll have lots more to say about that in Part II.

Q3:

Are there other actions?

A3:

ActionFixture has the actions start, enter, press, and check. However, as we'll see in Chapter 11, DoFixture tables may have any actions you wish.

Q4:

What happens if the start action is missing?

A4:

That could mean that the system under test has not been started and so an error would be given. However, we'll see in Chapter 6 that a start action is not usually used in the middle of a sequence of tables.

Q5:

What happens if the entered data is wrong?

A5:

If the entered data is of the wrong format, such as a date instead of a number, Fit signals the error in the table directly. If the application under test rejects it, such as the price should not be negative, Fit signals that in the table.

Q6:

What if we want to test that an invalid date is rejected, as expected?

A6:

We cover this general topic later, in Section 9.1 on p. 67.

Q7:

Couldn't the tests in Figure 4.1 be done with a ColumnFixture?

A7:

Yes, you're right. We could do it as in Figure 4.5, where the total() accumulates.

Figure 4.5. Fit ColumnFixture Table for Testing Buying Items

BuyActionsWithColumn
price	total()
12.00	12.00
100.00	112.00

Programmers

The fixture code for the tests here is given in Section 22.1 on p. 187.