Is TDD worth the extra effort? I got a reaction from one iOS developer who began applying my tips.
Andy Dwelly began applying my old Objective-C TDD screencasts to his iOS coding. Here’s what he writes in Some notes on Test-Driven Development:
Improve your test writing “Flow.”
Sign up to get my test-oriented code snippets.
At first, progress was almost painfully slow.
Yup. It seems like there’s a lot to learn. The real barrier is that there is a lot to unlearn.
When you first start applying test-driven development to real code, your productivity will take a hit. This is totally normal. But if you’re willing to press through the learning curve, your productivity will increase again, in ways you haven’t experienced before.
TDD: Immediate Benefits!
I would normally expect to write the final line and then fire up the debugger to get it to actually work.
Except that it did just work.
I experience this fairly regularly, even when I TDD a new view controller.
I think at this point if I’d been asked anything about the issue of code quality I would have claimed that the actual code produced was marginally better. My TDD code certainly handled errors and failures better but had poorer information hiding and some dependency injection that I would not normally have bothered with.
Then my tests found a bug that I don’t think I would have spotted until the code hit the field.
Do the math: What is the cost of fixing a defect vs. preventing a defect? Even though TDD takes more time up-front (when it’s just your time), it reduces time later (when more people are involved).
I think there’s enough evidence out there to make this claim: Once you make it over the TDD learning curve, your time-to-market will be the same—but with many more benefits!
Once you make it over the TDD learning curve, your time-to-market will be the same.
I’m still of the view that trying to do a lot of UX tests using TDD is hard.
What Andy hadn’t yet experienced is the real powerhouse that TDD enables: refactoring. To me, this is the greatest benefit of test-driven development. It’s a shift of emphasis, from ”prevent bugs” to “empower change.” And that’s why I’m vigilant about unit testing view controllers, down to the nib connections. Where some people say, “I don’t think that last bit is worth the effort,” my reply is, “It’s often not that hard. Why would you turn down the chance to check your code automatically?”
What are your questions / concerns / reservations / experiences with TDD? Leave a comment below.