Section 18.3. Workflow Tests
18.3. Workflow TestsWe now focus on design ideas and smells that apply to action, or workflow, tests expressed with ActionFixture and DoFixture. 18.3.1. Smell: Missing Sad Paths in ActionsDo you have a DoFixture table action that is colored green? Do you also define what happens when the action is rejected? Do the various reasons for the rejection need to be spelled out independently? We introduced the concept of sad paths in Section 15.5 on p. 121. To make the tests, and thus the application, comprehensive, spend some time on these sad paths in action tests. It may be easier to tackle the sad paths once the good paths are done. However, if you're not sure whether a new story is a good idea, it may be best to ignore the sad paths of the tests for that story until you're more certain. If you have less interest in the unusual and little patience for the odd cases, you'll want to get testers to tackle those; they have experience in doing so. 18.3.2. Smell: Calculations Slow with WorkflowAs we saw in Chapter 16, a large number of similar workflow, or action-based, tests may be radically reduced by clarifying the essential elements of the test, such as charging fairly for rentals. Instead of using many action tests, use a few tables of calculation tests for clarity, augmented with just a few action tests. If you find yourself repeatedly making copies of an action-based test and making small changes, this smell may well apply, as well as if you notice that many existing tests are similar. To understand a particular business rule when tests have this smell, it's necessary to read through many tests to work out what is going on by considering the few differences. The rule is lost in all the details. As we saw in Chapter 16, such tests can be refactored so that the essence of the various business rules can be expressed clearly and succinctly. Splitting the tests into those that are action based and those that are calculation based is the key (Section 18.2.8). 18.3.3. Smell: Long Action TablesWith long tables, it's more difficult to understand the test, because of all the details to follow. Consider splitting an action table into several, with each table grouping a few actions that belong together. Then support each of the tables with a little explanatory text (Section 18.2.3). 18.3.4. Smell: Unclear WorkflowAction-based tests usually have three parts.
An action-based test may have a problem under the following conditions.
18.3.5. Smell: Missing TestsAn action test may depend on a list of elements that have been set up, such as the single booked template entry in Section 17.6 on p. 148 and shown again in Figure 18.6.
If any of your tests are like that, have you assumed that the list has only one element? What if there are several elements? Or none? Or have you assumed that the list always has several elements? What happens if it has only one element? Or no elements? In general, have you written tests for all the important cases? If you leave one out, it may not be handled in the system under test. 18.3.6. Smell: Rambling WorkflowIt can be difficult to track state changes in a long ActionFixture, especially when a press requires many previous enters, corresponding to a DoFixture action with several data values. For example, the test in Figure 18.7 is long and difficult to read because of all the fine detail. This test could be improved by splitting it into several tables and adding text comments between the tables about the current state (see Section 18.2.3).
Where it will help readability, consider changing ActionFixture tables to use DoFixture, as we showed in Section 14.3 on p. 107. Are there many repetitions of a particular sequence of enter, enter, press in ActionFixture tables or of a sequence of actions in DoFixture tables? It may be possible to express that sequence with a single DoFixture action more directly, by substituting the single action for the sequence. The fixture can do extra work automatically when the test is run. 18.3.7. Smell: Similar SetupThe first three tables of Figures 18.8 and 18.9 are the same.[3] We can extract those three tables into a SetUp file or FitNesse page, as shown in Figure 18.10, so it's common across the tests. This makes it less work to add further tests. And when reading those revised tests, we won't need to read the SetUp repeatedly.
Figure 18.8. Test Remove Succeeds Figure 18.9. Test Remove Fails Figure 18.10. Common Setup 18.3.8. Smell: Convoluted SetupSometimes, the setup for an action test may be rather convoluted because it requires a series of actions to get the system under test into the right state for the essence of the test. So rather than having extra details that distract from the important part of the test, consider using SetUpFixture tables that more directly set up the appropriate state. A secondary reason for using SetUpFixture tables is to be explicit about the purpose of those tables in the overall test. (See Section 10.4 on p. 76 for details of SetUpFixture.) For example, consider the setup for testing bookings in the RentEz system. The set up can enter the existing bookings without needing to include the transaction and payment, as shown in Figure 18.11.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EAN: 2147483647
Pages: 331