I think the article was nice. I really would have liked a more concrete definition of the pattern and earlier in the article. I think the most important part of

I think the article was nice. I really would have liked a more concrete definition of the pattern and earlier in the article. I think the most important part of the article for me was: 1) Centralize all of our calls to other code in one place. 2) Share response values from each step with other steps. 3) Clearly delineate the order of steps in our code. 4) Make our code more maintainable and extensible by avoiding nested spaghetti code. I think test code should be the clearest, easiest, most lucid code. Even at the expense of code that in other contexts may be considered boilerplate or redundant. Test code serves a different purpose than production code and is made to be rapidly modified, quickly and dirtily refactored, and very easy to understand, and to be exceedingly clear as to what cases it is actually performing a run-time test on. Often I see authors writing test code as if the test code itself is built to be maintained and reused. In some cases that is true but generally not when actively developing a system.