3.2. Reports: Traffic Lights When Fit is run, it produces a report. The table cells are colored to show the results of the tests, so that we can tell which tests passed and which failed. This makes it easy to see which tests went right and which went wrong. Fit uses a traffic light metaphor for the colors in the report. Green: Test passed. Red: Test failed to meet expectations. Additional information may be provided. Yellow: Part of a test is not completely implemented, or something else went wrong. Gray: Parts of tables that have not been processed for some known reason, perhaps because a test is not completely implemented.
Other cells are left unmarked unless something goes wrong. A reported table may have rows added to it to provide extra information about failing tests. The results of the tests in Figure 3.1 are reported as shown in Figure 3.2 (see also Plate 1). The passing tests, whose calculated value of discount() is as expected, are green. The report contains a single failing test. This failed test is red because the system under test is incorrect when the amount is 1,000.00. The actual value that was calculated by the system under test (50.0) is added to the report. Figure 3.2. Fit Report for TestDiscount 
Tip The ordering of the test rows in this particular table is not important for automated testing, as the tests are independent. However, the order is important to the people who read and write such tests.
Are there any questions at this stage? Questions & Answers | Q1: | Are these tests, or are they requirements? | | A1: | They're both. The concrete examples help us to think about and communicate the important requirements to software developers. As the examples are in a suitable form, they can also be used to automatically test that the resulting software application does what's expected. | | Q2: | But the tests can't define all situations. | | A2: | That's right; we use concrete examples to give an idea of the general case. They need to be augumented with other forms of communication: general statements of the underlying business rules and discussion between the people concerned. | | Q3: | What if the business rules are not well understood or are changing? | | A3: | Creating the examples helps to focus on the essence of the rules. Examples serve as a way to sort out how we want to talk about the important issues that a system has to deal with. It can be easier to discuss business issues in the context of specific examples rather than trying to deal with generalities. The examples help to break down the important cases so that we don't have to deal with everything all at once. (We cover the dynamics of this process in detail in Part II.) If the business rules are changing, we need a way to express those changes and to talk about them. That may mean simply adding new examples to cover new cases. Or it may mean changing our terminology because the essence of the rules has to be altered. Either way, as we see in Chapter 18, it's important that we can change the Fit tests as the world changes. | | Q4: | What happens if you put something other than a number in a cell? | | A4: | When the wrong sort of data is in a table cell, an error is marked with yellow in the report that Fit produces. | | Q5: | Can we use values other than numbers? | | A5: | Yes; in general, a cell table can contain any sort of values, such as text strings, dates, times, and simple lists. See Section 3.4 for an example that uses simple lists. |
Programmers The fixture code for the tests here is given in Section 21.1 on p. 179.
|
