Revealing design flaws
Bad design is truly bad. It is the root cause of software being hard to change and hard to work with. You can never quite be sure whether your changes are going to work because you can never quite be sure what a bad design is really doing. Changing that kind of code is scary and often gets put off. Whole sections of code can be left to rot with only a /* Here be dragons! */ comment to show for it.
The first major benefit of TDD is that it forces us to think about the design of a component. We do that before we think about how we implement it. By doing things in this order, we are far less likely to drift into a bad design by mistake.
The way we consider the design first is to think about the public interfaces of a component. We think about how that component will be used and how it will be called. We don’t yet consider how we will make any implementations actually work. This is outside-in thinking. We consider the usage of the code from outside callers...
