Hey, we're in python!
We need a little program that will print out true if a test method gets called, and false otherwise.
Two things strike me with this exercise.
First, it reminds me of the practice of working through the "imperative shell" to discover where the boundary is going to be between the testable core and the humble object.
Second, it reminds me that this part of the exercise tends to be notable for its lack of ambition. It would be easy to imagine, for example, what the finished console output of running the test should be, and refactor the test toward that end. Instead, Beck starts with a trivial output, applying the Guru Checks Output pattern on the early runs.
Having created code that produces the correct answer (for this one trivial case), Beck now sets to work refactoring the exercise - beginning the march toward the design that is currently in his head (he may be taking baby steps, but the section title is "The xUnit Example" - he's working toward a specific framework).
We're not really looking at a test "driving" the design, at least not yet. Right now, the test is just the ratchet, ensuring that we don't lose ground as the code is cleaned up.
No comments:
Post a Comment