Test-driven development can help you with your software design.
People who make this claim sometimes emphasize the fact that good designs tend to be easy to test. This mislays the active force and makes a very simple process sound almost magical.
The important factor is not that good designs are easy to test. It's that bad designs are hard to test.
The effort to write a test has the potential to generate pain. This pain is often cited by detractors as reason not to adopt test-driven development. That's an effective argument because a lot of people see pain as a bad thing.
Pain is not a bad thing, though. Pain is a good thing. It tells us when a bad thing is happening and adds an incentive to remedy it.
The pain from writing tests is a good thing for the exact same reason. If you "listen" to the pain-signals created by the test-effort for a given block of code, you can "hear" when your design is bad. Sometimes, you can even detect where a problem exists.
It doesn't solve the problem of telling you how to fix a design. It doesn't solve the problem of helping you safely transit from design A to design B (although the presence of meaningful tests can). It just tells you that your current design might have a problem.
Yet, when you think about it, that's all we've ever expected from a test.
It's all we've ever needed from one, too.
