Chapter 11. Strategies for implementing acceptance tests
Christopher Alexander, father of the Pattern Language movement
We’ve now been introduced to acceptance tests, and we’ve gained an understanding of how to work with acceptance tests in the context of a team using an agile or iterative process. We’ve also taken a brief look into the Fit framework, which is probably the most popular acceptance-test tool around. Along the way, we saw what the technical representation of our acceptance tests might look like and roughly what is involved in automating those tests. In this chapter, we’ll change our focus toward the technical gotchas of making our acceptance tests—fixture classes, in the case of Fit—interact with the system under test.
The traditional craft of quality assurance (QA) with manual testing and scripted test cases[1] has long taught us to think of testing as being about testing the system as a whole, end to end, in order to verify functionality. And it makes sense. After all, we want to know that the system as a whole works correctly rather than that all the pieces work correctly in isolation. The world has more shades of gray than that, however. There is clearly value in testing on levels beneath the whole system. More than anything, it’s a question of cost versus value.
1 “Scripted” in the sense of “documented steps to carry out,” not in the sense of automating tests into executable scripts.