Revealing Design Flaws
Explore how test-driven development (TDD) encourages good software design by focusing on public interfaces before implementation. Understand how writing tests first helps avoid bad design, leaky abstractions, and missing tests, ultimately leading to code that is easier to use and change.
Good design
Bad design is truly bad. It is the root cause of software being hard to change and hard to work with. We can never quite be sure whether our changes are going to work because we can never really 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 go to waste 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.
Outside-in vs. inside-out
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 have yet to consider how we will make any implementations actually work. This is outside-in thinking. We consider the usage of the code from outside callers before we consider any inside implementation. This is quite a different approach for many of us. ...