In the following paragraphs, I will develop the application using test-driven development. You don't need to know TDD to understand what I will be doing. You will first be presented with a test asserting what the code should do as if it were already implemented, and then, just after, you will see the implementation.
But why use TDD in this book?
One reason is that I think it is easier to understand what the code is supposed to do by reading assertions about its behavior inside the test code, rather than inferring its behavior from implementation code.
Another reason is that it is easier to understand how to test a component while writing the component rather than having a (boring) chapter on testing components.
