Section 18.2. Fit Tests for Business Rules
18.2. Fit Tests for Business RulesFit tests are for communicating business rules. We have various ways to improve how we express those tests. We start with issues and approaches that apply generally, before tackling ones specific to particular table types. 18.2.1. Development of TablesWith simple business rules that are well understood, it may be easy to design Fit tables for expressing suitable tests in one go. Often, however, various issues have to be understood and dealt with, making it difficult to get under way on writing a test. Let the tables evolve. Start with simple examples and gradually make them more complicated, as we have shown in earlier chapters. There's no need to make the examples comprehensive to start with; leave detail out until you've made progress and you're ready to tackle it. Be prepared to change the names in header rows and actions as the table structure evolves. Short names may make sense to you at the time, but will you or others remember what they mean later? Choosing a name may not be easy but can aid in improving understanding. Tables need to be clear. Can they be named well? Table smells may be the result of badly organized tests or may show that there is a problem in understanding what's required from the stories. Confusion in identifying or clarifying a business rule may be muddying the waters for the test that you're trying to write. 18.2.2. Meaningful ExamplesAs much as possible, use meaningful examples in tests. It will help everyone better understand how things are. Often, the subtleties of the real world may show us that our ideas about a business rule are too simple, forcing us to deal with all the relevant variations. Because they often have an insufficient idea of the context in which the systems they build are used, programmers need all the help they can get. It's possible that tests may also be used to automatically generate online and offline user documentation, so it's handy if they're likely to be meaningful to the readers. The use of meaningful examples is illustrated best in this book by the tests in the chapters in Part II. 18.2.3. Supporting TextUse headers and comments to organize your test files and make them easier to read. Include descriptions of business rules with the tables or in related pages with FitNesse. Where they're useful, include images that help the reader understand a test and the underlying business rule. The examples in this book tend to have little supporting text, owing to space limitations. The example test in Section 10.2 on p. 74 is clear in intent and reads easily. 18.2.4. Smell: Meaningless NumbersFigure 18.1 illustrates this smell. In the first column, numbers are used instead of meaningful names for the three possible values: low, medium, and high, as used in Figure 5.7 on p. 34.
Meaningless numbers in Fit tables are confusing and require that we repeatedly have to remember or look up what they mean. This makes the tables difficult to read and to check by hand. 18.2.5. Smell: Poor NamesFigure 18.1 also illustrates this smell. The header labels are not very useful: The value of what? The max of what? There's no point in expecting the reader to remember. The full labels, as used in Figure 5.7 on p. 34 are more useful: future value, max owing, min purchase, and discount %.[1]
Poorly named fixtures, test files or pages, header labels, or actions mean that we and others have to remember what they're about. Good names can be very helpful in reminding us of the purpose of a part of a test. They help us when we introduce a test to someone else. Using the appropriate business terminology can speed things up, as long as uses of a term are not contradictory. It may seem easier to write a short name for an action because we know what that means now, while we're thinking about it. But consider the many times that someone will read the test or a related one in the future; make it meaningful now. It may seem easier to not change a name as your thinking about it changes. But build your best approach to meaning into a name. Again, realize that the name is for communicating something, and we need to think of those readers in the future, including ourselves. Confusion over names may be the result of a quick decision or may point to one or more underlying problems with a Fit test.
18.2.6. Smell: Brain TwistersLook at the booking tests in Figures 18.2 and 18.3. The from and to values in Figure 18.22004/05/06 11:11 and 2004/05/07 09:11differ by the amount of the for values22 hoursin Figure 18.3. Which test is quicker and easier to read? When the time difference is important to the test, make the value obvious.
Keep the following points in mind. Is it difficult to determine whether a particular test is correct? Is there an easier way to express it so that you don't have to work it out? Express the tests as simply as possible, even if that's not the way it's likely to be handled through the user interface. 18.2.7. Smell: Unnecessary DetailA test should focus on the essence of the business rule, avoiding unnecessary details. For example, because it was not relevant, Joanna's address was not included in any of the tests we saw in earlier chapters of this part. Verbosity in Fit tables simply hides the intent of the test. The biggest smell arises when Fit tests for general business rules are expressed as operations through the user interface: "Select the Open menu item. Enter Joanna in this field."[2] There are likely to be many user interface operations that can be expressed succinctly as more abstract actions.
There is a synergy between this smell and the one in Section 18.6.3. Unnecessary detail causes problems when things inevitably change. Questions & Answers
18.2.8. Smell: Tangled TablesTangled tables arise when a variety of interrelated tests are mixed together. You can suspect that a test is tangled when it is long and convoluted and/or many tests are similar but differ only in small details. We avoided creating tangled tables in Section 13.5 on p. 98, when Don decided that "the grace period calculation would be best done independently." Instead, a grace period value was included in the late-return tables, and the calculation of an appropriate grace period, based on the rental period, was done elsewhere. For a larger example, consider adding tests for bookings of rental items in the RentEz system that was covered over the past few chapters. In developing those tests, we find that several issues need to be clarified.
It is a trap to try and deal with all these issues at once in a set of tangled tests. It is essential to separate the business rules involved to be clear about them.
See Section 18.3.2 for one way to untangle tests. 18.2.9. Smell: Split ValuesAs we saw in Section 16.3 on p. 131, it was worthwhile handling time durations as single values in a cell instead of using several cells. For example, Figure 18.4 shows a table in which hours, days, and weeks are in separate columns. However, this makes it a little more difficult to read. More important, it requires that all columns be filled in, even if they're not relevant, such as 0 for most of the hour values in Figure 18.4.
Figure 18.5 shows a refactored table in which the duration of hours, days, and weeks is a single value.
In general, consider whether a value that is split over several cells would be better expressed as a single value in a single cell. It can be false economy for programmers to avoid writing fixture code to handle such values or to improve the expressiveness of Fit tests in general. Putting a little effort into the fixtures can lead to better tests and to reductions in the efforts of the test writer and the reader. 18.2.10. Smell: Long TablesIf a table is very long, perhaps it can be made clearer by splitting it into several tables. There may be a way of organizing it so that the separate tables are meaningful units. We can then explain each of the tables with supporting text (Section 18.2.3). 18.2.11. Custom TablesAs we mentioned in Chapter 11, your tests may have a pattern that you're unable to exploit with the existing fixtures. It means that the tests are larger than they need to be, because they don't express things directly. People have a powerful visual ability that can quickly process and understand tests that show important associations spatially. So go ahead and make up a custom table, and talk to the programmers about making a fixture for it. For a few examples, see Chapter 11. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EAN: 2147483647
Pages: 331