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!
Chapter 1 starts off with a surprising answer to the question, “Why write unit tests?” Why, to make more money! It shows how the traditional handoff-to-QA form of testing comes from the waterfall model of development, and how the cost of fixing defects increases with each phase of the waterfall.
Chapter 2 lays out the principles of Test Driven Development: test first, writing “Just Barely Good Enough” code that satisfies the test, and refactoring. But it also describes an important principle from Extreme Programming: “Ya Ain’t Gonna Need It,” or YAGNI. Basically, code only what you need to. This keeps production code simple, and avoids wasting time writing code that won’t have any effect.
The book goes on to introduce unit testing by showing how one might write tests without a unit testing framework — the old-fashioned way! Then we get an overview of the more common tools. Finally, we hit the meat of the book: a full example of creating an iOS app using TDD, spanning five chapters.
How do you learn Test Driven Development? I could explain the principles and practices of Xcode TDD, but the question that comes back is, “But what do I actually do in Xcode?”
“Kata” is a Japanese martial arts term for choreographed patterns of movement. Also called “forms,” both students and masters practice these detailed patterns over and over, so that the movements can come without thought.
A “code kata” applies this idea to coding. Some use the term to refer to coding puzzles in general (how would you code this or that). But let’s follow the martial arts metaphor to see where it may take us. A code kata is a set of moves, meant to be memorized and practiced until they can flow effortlessly.
So a “TDD kata” is designed to train your TDD muscles. Robert Martin designed the Bowling Game Kata to impart the moves of Test Driven Development. I have taken his presentation and created a version showing these moves in Xcode, using either Objective-C or Swift.
Test Driven Development: Does it work for iOS apps?
Short answer: Sure! Here’s an example:
Longer answer: “eBay Instant Sale” went live in the App Store two days ago. I can’t share the source code with you, of course. But here’s the unit test coverage:
It was written almost entirely using TDD. Sometimes tests weren’t written first (especially the code by a new engineer I couldn’t mentor because I was away). But test first or test last, they got written.
“That’s fine,” you may say, “but what benefit did they have?” If you’ve never done TDD, you haven’t felt the empowerment it brings. Read the following statements twice: