TDD is a process that produces multiple values for the organization. One of them is a fundamental improvement in the quality of the products they produce. This is not just because of the testing per se, but also because of the effect of writing them up front. This episode explains why.
TDD Improves Product Design Quality
The focus of our efforts should always be centered on the product and the value it provides. Software is no exception because it either is the product, or it is part of a product. Either way the product is the point.
One critical aspect of this focus must be the quality of the product itself. Poor-quality products have less predictable value, are difficult to debug when needed, and difficult to make changes to when new requirements, market pressures, or opportunities arise.
I've been teaching software design for over 20 years, usually using Design Patterns as a way to illustrate what good design is. I also teach analysis techniques to help developers understand what they should be making, and to ensure that they do.
When Test-Driven Development came along, I initially thought "well, sure, testing is a good thing. Doing more of it is probably a good idea." But eventually I began to realize how strongly it related to good analysis and design as well.
First, it is very difficult, if not impossible, to write a good test about something you don't understand very well. Of course, if you don't have that understanding it's probably unwise for you to try to design the solution yet! TDD tests are extremely unforgiving because of their precision. They hold your feet to the fire, so to speak, and force you to ask yourself if you fully understand what you're about to build. By writing tests up front you find out quickly if your understanding is sufficient and, if it is not, will even suggest to you the questions you need to ask before you continue.
Secondly, as anyone can tell you who's tried to add tests after the fact to an older system, bad design is very hard to test properly. When the tests precede development, if they are difficult to write it is almost always because the design of the product is poor. The pain you feel when trying to test it is a diagnostic tool, as all pain is.
But there is a little trick here. Note that in my first point I mentioned a "good" test. In the second I said to "test properly." So, the critical question is: What is a good test in TDD? What does it mean for it to be proper? It turns out that the answer to this question is quite different from the one you'd get from a traditional tester and so TDD practitioners must have a deep understanding of how TDD-style tests should be written.
Not surprisingly, that's a big part of what we teach in our TDD courses.
So TDD promotes good product design for the simple fact that it will not allow for anything else, which is a good thing. It ensures that we build things well. Of course, we also must build the right things, which is all about collaborative analysis. I'll address that next week.
See the transcript for details on our TDD courses:
https://www.pmi.org/business-solutions/agile-training/technical-solutions