Using a hammer to drive in a screw. I mean, it works, kind of. But if you use a tool in a way other than its intended purpose, you’ll be missing its most important benefits. It’s kind of like that with Test-Driven Development.
Is TDD about preventing bugs? That’s more of a side effect than a direct goal.
Is it about making a test suite? Well, kind of. But… no. Not really.
What is the test suite for? Until you know the intended purpose of Test-Driven Development, you may apply it incorrectly. TDD may seem like wasted work. And without some guiding principles, you won’t know how to optimize your TDD to get the most out of it.
So let me just lay this card on the table: TDD is about feedback. Fast feedback.
Let’s look at how it works in the three steps of the “TDD Waltz”:
So you want to try Test-Driven Development — great! But that requires expressing the intent of the code-to-be in automated tests. Where should you start if you don’t even know what the code should do? What should you do if you’re not confident about a particular approach?
You drive a spike through it!
It’s one thing to say, “Do test driven development.” But practicing TDD requires a set of tricks — you need techniques to enable test driven development in your particular environment. It’s these techniques which I hope to pass on to you through a case study of building an iOS TDD sample app.
I’ve accumulated a treasure chest of TDD ideas over the years. These ideas are often not my own, but are other people’s ideas which I collect and curate. Some are about object-oriented design. Some are about working in Xcode and Objective-C. And some are particular to iOS development. I’ve collected many, and continue to gather new ones.
I’m building this TDD sample app so that you and I can browse through this treasure chest together. You may have tried test driven development and given up on it. Or maybe you’re still trying, but finding it frustratingly slow. The ideas we will explore together will help you break through to make headway in your TDD journey, so that you can experience the freedom and ease that comes from automated testing and clean code.
The results of my reader survey are in. The #1 request? Case studies of unit testing, with more complex examples. And that got me thinking about the next major direction to take this blog.
When I was first learning Test-Driven Development, I didn’t really have any examples to look at. All I had were descriptions of TDD. I stubbornly believed that these descriptions showed a more effective way of programming, so I fought my way there through the School of Hard Knocks.
But you shouldn’t have to do the same.
Remember my iOS Model-View-Controller TDD screencast? Eric Baker took it a few extra steps with his own follow-up screencast, demonstrating:
There’s a lot of interesting stuff here. But I also want to acknowledge that this screencast changed my mind about dot notation. Yes, really!
What are your thoughts about ReactiveCocoa, Kiwi, or AppCode? Leave a comment below.
The UIViewController TDD screencast ended with all the code in the view controller. Unfortunately, this is where many iOS programmers leave things! Let’s TDD our way to something better…
In part 2, we pick up from there and TDD to extract a model class, which the controller observes. You’ll see it evolve into true Model-View-Controller, driven by unit tests.
In particular, you’ll see how to TDD:
Is TDD worth the extra effort? I got a reaction from one person who tried applying my tips.
Andy Dwelly began applying my TDD screencasts to his iOS coding. Here’s what he writes in Some notes on Test-Driven Development:
At first progress was almost painfully slow.
Yup. It seems like there’s a lot to learn. The real barrier, I think, is that there is a lot to unlearn. When you first start applying Test-Driven Development to real your 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…
This screencast focuses on the question I get the most: “Do you do test-driven development for view controllers?” It’s clearly a roadblock for many people. This screencast should remove that roadblock.
It also answers the question, “Is it worth doing?”
TDD is a series of small steps. It can be difficult to grasp until you see those steps demonstrated.
That’s why I made this screencast. It was sparked by a Stack Overflow question that said, “All the examples of unit testing I read about seem to be extremely simple and trivial.” The question asks how to write unit tests for a piece of sample code that uses NSUserDefaults.
Many programmers assume that Test-Driven Development doesn’t work well for iOS development. This ill-founded assumption really comes from a lack of any experience with TDD. But because iOS developers learn most of their chops by referring to other people’s code, it also comes from a lack of helpful examples.
Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.
So I was really glad when Graham Lee’s book Test-Driven iOS Development came out. Finally, something I can point others to besides my code!
How can you learn Test-Driven Development? I could explain the principles and practices of TDD. And yet the question that comes back is, “But what do I actually do in Xcode?”
That’s what code katas are for. They’re not tutorials. They’re exercises. Let me introduce you to a few that are set up to go in Swift. Then you can try doing one today.
(I’m in the middle of rewriting this post, so it’s “under construction.” Instead of focusing solely on the Bowling Game, I list a few different exercises. Then we’ll drill into the Bowling Game.)
Test-Driven Development: Does it work for iOS apps?
Short answer: Sure! Here’s an example:
Yeah, that’s a really old image, and no, you can’t find this on the App Store anymore. But this was an app published by eBay. Here’s the unit test coverage: