Test-Driven Development for iOS: Alien, or Natural?

Hi, I’m Jon Reid, the founder of this website and the consultancy Quality Coding, Inc. Back in 2001, I was looking for safer, saner ways to code. I came across Extreme Programming, a set of practices that predates “agile” as we know it today. Test-driven development (TDD) is one of these practices.

Here’s a simple explanation of the TDD workflow. We repeat three steps:

1. Write a single unit test that fails.
2. Write the most obvious production code that passes the test.
3. Now that it works, refactor: clean up both production code and test code.

Repeat these three steps over and over. There’s a lot of nuance in how these steps work, what each step is for, and the purpose of each transition to the next step. But these three steps are the essence of TDD.

iOS has a cultural problem

On the face of it, there’s nothing special about test-driven development for iOS. You still do these same three TDD steps as anyone else. But when we’re learning to work with Apple’s frameworks, we usually learn by trying sample code. And the fact is, very little iOS sample code is written to show test-driven development. It’s not even written to show testable code. Actually, you’re lucky if you see any examples of tests.

Some of this is due to the nature of sample code. Much of it comes straight from internal Apple culture. I’ve been on the inside. Testable code is rarely a concern there, much less test-driven development. There are people and teams inside Apple trying to change that, but changing any culture is a long road.

That’s why I wrote iOS Unit Testing by Example. My initial goal was to write a book about TDD for iOS. But after a survey, I found the biggest barrier to TDD on iOS wasn’t necessarily the TDD itself. It was the lack of knowing how to write unit tests for ordinary iOS code. So I pivoted, and wrote a book hoping to address that problem.

Because you can write unit tests for iOS without unusual patterns. Sure, you can apply “functional core, imperative shell” style which makes it much simpler to write tests. But this is alien to most iOS developers. I wanted to show that you don’t need to adopt advanced architecture before testing, or doing TDD.

Test-after isn’t good enough

You may ask, isn’t it good enough to write unit tests after production code? The answer is no.

Folks who live by test-after focus on two separate goals: First they write all the production code changes they want to commit. Then they write tests, hoping to prevent any breaking changes that may come later. The goals are “make it work,” then “add test coverage.”

The goals for test-driven development are rather different. The three steps lead to different results. Adding tests isn’t a goal, it’s a means to a different end: refactoring.

Refactoring means we change the design of the code. As long as the tests pass, we can discover whatever shapes make sense for the code. With test-after tests, it’s easy to write tests that lock down the production code. But the TDD mentality is to encourage changes to the code.

If I write my tests after, I'm likely to couple them to the existing code structure and then they guard against change instead of against failure. I want change. — Tim Ottinger

I’m your local guide for iOS TDD

I started TDD in 2001, working in C++ on Mac and Window. In 2005 I began to apply it to Objective-C. Then I got my first iOS job in 2010. Continuing test-driven development when I started iOS was never a question for me. I didn’t know any other way.

Perhaps that makes me a native of the iOS TDD land, instead of an immigrant. An immigrant—and we need more of these!—enters a new land and has to relearn everything. New language, new culture.

When you move to a new land, one of the best ways to get acclimated is to get a local guide. Someone who is intimately familiar with the culture, because it’s their own culture. For test-driven development in iOS, I am one of those guides.

As Apple technology continues to shift, we’re all learning. Every new piece makes us all beginners, and there are many good sites about the Swift programming language. But if you’re looking for guidance on TDD for iOS, I can provide the training you need.