Section 18.4. Calculation Tests

18.4. Calculation Tests

We now focus on design ideas and smells that apply to calculation tests expressed with ColumnFixture and CalculateFixture.

18.4.1. Smell: Many Columns

A ColumnFixture or CalculateFixture with many columns may indicate that something is wrong. Is there a tangle of tests here (see Section 18.2.8)? If so, can they be split into separate tests with distinct tables?

Are there many repeats in a big table? If so, maybe they can be eliminated by breaking the table up into several smaller tables, with common column values expressed as arguments. For example, one such table from Section 16.3 on p. 131 is shown again as Figure 18.12.

Figure 18.12. Table with Arguments

18.4.2. Smell: Not Calculating

Consider the table shown again in Figure 18.13. This table is using the form of calculation tests, but the intent is to set up for an action test. It's clearer to use a SetUpFixture table, as shown in Section 10.4 on p. 76.

Figure 18.13. Setup Table Using ColumnFixture

DiscountGroupsEntry
future value	max balance	min purchase	discount percent	add()
low	0.00	0.00	0	true
medium	0.00	500.00	5	true
medium	500.00	500.00	3	true
high	500.00	2000.00	10	true
high	1000.00	500.00	5	true

ColumnFixture tables can also be used for actions tests. For example, the ColumnFixture table in Figure 18.14 is testing that a rental return leads to the correct refund. The returns() column checks that the return succeeded; the running total() column checks the amount of the refund. This test can be expressed a little more clearly by using a DoFixture table without being confused as a calculation test.

Figure 18.14. A ColumnFixture Used for Action Tests

hire.ChangeRentals
rental item	count	days	returns()	running total()
coffee urn	5	1	true	-100.00
hot water urn	2	1	true	-140.00

18.4.3. Smell: Many Rows

As we've already seen (Section 18.2.10), long tables may need to be organized into several tables to help the test reader and the writer. For example, in Section 13.6 on p. 99, we suggested that a separate table be used to define the late-return business rules when the high demand is not zero. Figure 18.12 shows one of several tables that define fair charging, based on time and the various charge rates.

In general, long tables can be split to create separate tables for the major cases. Order the rows in the tables clearly to make it easier to see the organization and easier to see whether cases are missing. Use blanks with ColumnFixture rather than repeating the same value down a column. Or use table arguments, as we saw in Section 18.4.1.

18.4.4. Smell: No Related Workflow

For any business logic that is tested as calculations, we'd expect to see two or more action-based tests to define what happens under the various circumstances. For example, if we have calculation tests that validate some data input, such as a date, we'd expect to see what happens in the workflow when it's valid and when it's not. For example, we have not shown any action tests for the late-returns tests covered in Chapter 13.