There’s been a growing debate about static languages vs. dynamic languages. For me, it started with Uncle Bob’s Type Wars, but it has expanded into many circles. Writing my own reaction helped me discover that I was unfairly judging Swift based on C++.
In the midst of the debate, another interesting article popped up: Eric Elliot’s The Shocking Secret About Static Types. It points to a couple of studies. One concludes that there is a lack of evidence that static typing reduces defect density. The other more rigorous paper concludes, “There is a small but significant relationship between language class and defects.”
Check out Eric’s fascinating conclusion:
We’ve come full circle: a discussion about static types has again brought us back to TDD. Why?
Right now, we get different levels of information from our IDEs.
But even more analysis is possible, beyond what Xcode gives us:
Please understand: I want every bit of feedback I can get. Even Xcode’s powerful static analyzer doesn’t go far enough for me. I want more!
Imagine a perfect IDE. It unambiguously shows two states: red / green. It tells you if the code is working.
It’s not really possible, is it? I can use off-the-shelf tools, from Xcode to OCLint, to catch syntactic errors. But an off-the-shelf tool is never going to understand the semantics.
The only way to have my imaginary IDE is to have a custom tool that understands my domain requirements.
But it’s not imaginary. It’s what you get from Test Driven Development.
For those of you who don’t practice TDD: I understand the desire for that “small but significant” reduction in defect density. Hey, I work on projects with legacy code (that is, code without unit tests). When dealing with large swaths of legacy code, I want every tool I can bring to bear on the code. Apple announced Xcode 8 yesterday, with more warnings and static analysis? Yes, please! Like I said, I’ll take every bit of feedback I can get.
And there are classes of bugs that TDD doesn’t address. Like memory leaks.
But if you stop at static analysis, you’re selling yourself short. Build domain-specific dynamic analysis tools. They’re called unit tests.
Here’s the thing: if you want to beef up your unit tests, doing so after the production code is hard work. It’s much, much easier to do them in parallel, with the test code leading the production code.
Welcome to Test Driven Development: dynamic analysis tools customized to your domain.
Are you ready to take a step further with unit tests? Leave a comment below to share your journey.
Jon is a coach and consultant on iOS Clean Code (Test Driven Development, unit testing, refactoring, design). He’s been practicing TDD since 2001. You can learn more about his background, or see what services he can bring to your organization.