Section 3.3. Calculating Credit

3.3. Calculating Credit

Here's the business rule for our second example of using a ColumnFixture table to test calculations.

Credit is allowed, up to an amount of $1,000, for a customer who has been trading with us for more than 12 months, has paid reliably over that period, and has a balance owing of less than $6,000.

Again, we use a table to define whether credit will be extended, based on the values of the various given characteristics of our customers. A small set of tests for this business rule is shown in Figure 3.3.

Figure 3.3. Fit Table for Testing Credit

CalculateCredit
months	reliable	balance	allow credit()	credit limit()
14	true	5000.00	true	1000.00
0	true	0.00	false	0.00
24	false	0.00	false	0.00
18	true	6000.00	false	0.00
12	true	5500.00	true	1000.00

The first row of the table names CalculateCredit, the fixture, which determines how the examples in the table are to be tested automatically against the system under test. In this book, we follow a convention that fixtures that test calculations have Calculate in their name.

The second (header) row of this table, as usual, labels the given and calculated value columns for testing creditworthiness. Two columns have calculated values: allow credit() and credit limit(). The given value of reliable and the calculated value of allow credit() will be either true or false. As is usual with ColumnFixture tables, the test rows are independent of one another.

In Figure 3.3, the four cell values in italics indicate that credit is refused. Test writers can format Fit tables to better organize them, as we'll see later, and format cells values of special interest to highlight them.

Fit reports the results as shown in Figure 3.4 (see also Plate 2). In each test row of the report, the two cells for the calculated results that are expected are marked. The tests in the first four rows are right and are marked in green. The last row of the table fails, with two cells marked wrong, in red.

Figure 3.4. Fit Report for TestCredit

In general, a test can fail for several reasons. For example, in the report in Figure 3.4, the failing test itself could be incorrect, or the business rule may be stated incorrectly for the case of exactly 12 months.

Looking Ahead

Note that we don't test the business rule with specific customers; we have abstracted away from the table how we determine those characteristics for particular customers. We discuss such design issues for tables in Chapter 18.

This set of examples is fine for giving a sense of the business rule. However, they are incomplete from a tester's perspective. We'd need more tests to make sure that the business rule has been understood and implemented correctly in software. Testers have expertise in the art of choosing such test cases.

These tests are also badly organized. It's not easy to see what the rows are testing and what is missing. We take up this issue in Chapter 18.

You may have noticed the subtle redundancy between the two calculated fields. The value of credit limit() always depends, effectively, on the value of allow credit(). Redundancy, and why we want to avoid it in the design of tables, is discussed in Chapter 18.

Finally, in some situations, the rows of a ColumnFixture table are not independent, by choice, as we show in Section 4.1 on p. 23 and in Chapter 13.

Questions & Answers

Q1:	What if we want to use yes and no instead of true and false?
A1:	They can be used instead in FitNesse (Chapter 8), where yes, y, 1, and + can also be used for true. Anything else is false.
Q2:	What if a given number is negative, which is not valid in the application?
A2:	We take up this issue in Chapter 9.
Q3:	What's a fixture?
A3:	A fixture is the "glue" that connects the tests in a Fit table to your application. From a programmer's point of view, a fixture names the software that is responsible for running the tests in the table against the system under test. Different fixtures may do different sorts of tests. Part III covers this in detail.
Q4:	Will a whole test sequence be included in one table? Some of our tests go on for many pages.
A4:	No, not necessarily. We'll see in Chapter 6 that a test sequence may consist of many tables of varying types.

Programmers

The fixture code for the tests here is given in Section 21.2 on p. 182.