3.5. Summary Fit tests are defined in tables. ColumnFixture tables are good for specifying the expected calculated value based on the given value in a row. The test writer gets to choose the names of the labels in the header row, such as phones and first(). Each row of a ColumnFixture table represents an independent test when it's used for testing the same calculations on different data. We'll see ColumnFixture tables in Section 4.1, where the rows are not independent, and so their order is important. When Fit runs a test, it produces a report. This report gives feedback on the test by marking parts of the input table according to what passed. We've seen several examples of ColumnFixture tables; the second table had two calculated columns.
The next chapter introduces action-style tables. However, if you'd like to start using Fit on ColumnFixture examples first, you may like to look now at Chapter 7. Questions & Answers | Q1: | We have lots of tests in text files. We wouldn't want to make tables from them. | | A1: | You don't need to do so. As we'll see in Chapter 7, tests in other input formats can be fed into Fit. However, some straightforward programming will be required for custom data formats (as discussed in Chapter 39). | | Q2: | Our existing tests all center on the process of using the system. There are no "calculation" tests. | | A2: | Often, tests are written in this way because the only way to check them has been to run the system through the user interface and carry out a sequence of steps. When we look more closely at those tests, we often get an inkling of the underlying business rules. As discussed in Part II and especially Chapter 18, we aim to extract those essential business rules and express them independently of the work flow. That extraction has several benefits. We gain clarity about the rules. By expressing them succinctly, we can more easily discuss the rule and see what cases (examples) we may need to add or change as the business changes. It is much faster to create the (short) examples, as they can ignore the workflow. The tests are not dependent on the user interface, which is often the part of a system that changes the most. Those tests can be made to run much faster, if necessary. | | Q3: | But that assumes that we can test the business rules in isolation! | | A3: | Yes, it seems to assume that. We discuss various ways for programmers to manage this in Chapter 33. | | Q4: | How do we decide on suitable tests for our application? | | A4: | We'll cover that in some depth in Part II, once we've seen several examples of various sorts of tests. The process of writing tests usually starts from thinking about the important things in your business domain and what you want to say about them. That's what we're calling "business rules." In some cases, they're quite obvious; in others, they come out of clear thinking about what's needed by exploring with concrete examples. If you now want to see how Fit tests are created, skip ahead and read Chapters 12 and 13. The chapters after those two may not make complete sense; you will probably need to come back and read more of the chapters in this part first. | | Q5: | How do the programmers know what to do with a Fit table I've written? | | A5: | To write the fixture code, they may need to talk to you about what you intend with the test. After that, they'll know what to do with similar tables. |
|
