Book Club: "Test Driven Development: By Example" #15
Chapter 16: Abstraction, Finally
Now we're coming to the end of this example!
We want to test the plus() method on Sum, and Beck calls our test code a Rosetta Stone. It should read clearly, and be close to our actual design, ie we create a Sum explicitly that we can use to get the result we assert on. We don't have to do that, but we will, to illustrate how the code is intended.
Beck talks about economy, saying that tests written with TDD will be about as long as the code itself and thus to maintain economic sense, you need to write code faster, or use less code for your purpose. Perhaps this is true, although... we're working without refactoring the tests to DRY up the test set up so perhaps not. But, I find it a weird thing to say, since the economy of writing and having lines of code isn't the measure of successful software.
People who aren't convinced by TDD tend to complain that the cost of TDD is too high because writing code for the tests is slow. But, since the tests are a side-effect of driving design, TDD keeps you and your team working faster long-term; even if you are maintaining twice as many lines of code.
There's one chapter left in Part One of the book, which retrospects on the Money example.
🔎 View my code-along repo at https://github.com/ruthmoog/test-driven-development-by-example
Top comments (0)