One of the principles of agile software development is to “respond to change.”[1] Agility sounds appealing, but these days it is often approached as a project-management tool. Yet we are developers, working in code. The more the code itself resists change, the harder it will be to adopt agility in any meaningful way.
But we can change this—because we are developers, working in code. There are disciplines that fall under the term “technical agile practices.” Among these are unit testing, refactoring, and test-driven development. These are some of the tools we can use to make code pliable so we can safely bend that code into new shapes.
I’ve been learning to apply these disciplines in the workplace since 2001. Lately I’ve been teaching “Test-Driven Development for iOS” workshops.[2] So it seemed a safe bet that if I ever wrote a book, it would be about TDD.
But I realized that folks can learn theoretical TDD, but still be stuck on iOS particulars. Because if you don’t know how to write unit tests for iOS code, how can you ever TDD it? So my book plans pivoted, and here we are. My goal is to give you solid handholds so you can unit test your iOS code.
Apple’s framework for the user interface, UIKit, lies at the center of iOS code. And the center of UIKit is view controllers. That’s why I focus on unit testing view controllers.
It may seem counterintuitive to test UI-centric code using unit tests. As soon as one sees “UI” or “view,” it’s easy to assume that “UI tests” are the best fit. But UI tests don’t provide the level of control and fast feedback that unit tests give. UI tests are more about automating tests for quality assurance. Unit tests, when they are very fast, serve a different purpose. They become a development tool, helping you bend the code so you can “respond to change.”
So let’s learn how to write unit tests for iOS apps. But keep in mind that the unit tests themselves aren’t the goal. They’re not the end, they’re the means.