Until now, we've left the concept of test-driven design (TDD) out of discussion. Now that we have some experience in applying TDD to concrete problems, it's a great time to discuss some of the less concrete aspects of it.
Test-driven design has a notion that the biggest value we see from TDD is the result of the code that we design. It's completely fine if this is not immediately obvious. Think about it like this: how does code that is designed with the help of TDD differ from code that is designed up front, and then written? The code designed with the help of TDD is done incrementally, and in response to how effectively the current design is solving problems. Think of your tests as the first "user" of your code. If the code is difficult to test, then it is also probably difficult to use.
We saw an example of this when we built our Naïve Bayes classifier. We were heading down a route that was becoming increasingly difficult to test. Instead of charging ahead without testing...
