A robust suite of unit tests acts as a safety harness, giving you courage to make bold changes. But there’s an art to making tests that give you useful information, while keeping the tests themselves readable & maintainable.
Success with iOS unit testing comes down to 3 factors:
XCTest is your primary tool. Learn how to control it. Learn its subtleties. And learn how its launch sequence affects your tests.
View controllers lie at the center of iOS coding. Just because it’s “UI” doesn’t mean we need UI tests. Unit tests give developers faster feedback, with greater control.
Typical iOS code is filled with implicit dependencies which get in the way of testability. We need ways to manage them, and replace them with substitutes or Test Doubles.
My book iOS Unit Testing by Example: XCTest Tips and Techniques Using Swift is the definitive guide to unit testing iOS apps. It covers some basic tools and skills, testing specific behaviors of iOS apps, and how to use the fast feedback from your tests.
Below are the most important articles I’ve published, to help you manage difficult dependencies, test your view controllers with unit tests, and control the test framework.
Test cases depend on their infrastructure. Let’s take a look at some of the ins & outs around XCTest, and how the framework interacts with your production code.
Difficult dependencies: can’t live with them, can’t live without them. We need ways of putting such dependencies behind a wall, and replacing them during testing. Swift gives us various ways to do that.
The idea of unit testing view controllers may sound silly at first. Shouldn’t you use UI tests to test UI components? But if you can tame view controllers with unit tests, you’ll have a much better developer feedback loop.
Here are my latest articles that aren’t listed in the groups above yet:
I’ve created a class that guides your team through my unit testing approach. It covers XCTest foundations, unit testing view controllers, and managing hard dependencies.
It contains what I’ve learned from applying a developer-centric testing approach to iOS apps — skills I’ve been using for the last 9 years.
Hi, I’m Jon Reid, the founder of this website and the consultancy Quality Coding. I create content about unit testing because it’s been so important for my journey as a developer.
When I first left small coding shops and entered the big leagues, I was stunned by how much code there was in a single app. Or even in a single module. One coded until it “works for me,” then pushed straight to the shared repository.
This led to a mountain of bugs. I mean it — the bug count formed a bell curve called a “mountain chart”. Bugs heaped up, unresolved, while developers worked. They continued to pour in while the find rate was greater than the fix rate. At some point, QA called it “good enough” and it shipped, even with hundreds of known issues.
In this environment, it was easy for complex code to become more complex. Fixing one problem often created another — but you wouldn’t know it for some time. Eventually, I saw there were sections of code the developers were afraid to touch. You never knew when you broke something.
The great thing about a strong suite of unit tests is they can check thousands of details for you. And unit tests are fast. You get the test results in seconds.
This combination of spread and speed is liberating. It means you no longer have to be afraid. And that means you can make changes boldly.
But why should we have unit tests for iOS code, when most of the app is view controllers? Shouldn’t we use UI Tests for UI?
The thing is, they serve different purposes. UI simulate human touches, so they’re easy to understand. But testing the entire app, end-to-end, has big costs:
Test pieces of code
Test entire app as opaque monolith
Directly load a view controller
Navigate to a view controller
The big difference between the two is what they operate on. Apple’s UI Tests touch the app from the outside. As a result:
But unit tests call the app’s code from the inside:
Unit tests can give you feedback as you code. This makes them a coding tool.
I’ve been working with unit tests on Apple platforms since 2001. Mac OS X was a big step forward, because it was based on NeXT technology. Then iOS grew out of that. I started working on iOS in 2010, applying my Mac unit testing experience. This was before Xcode had built-in support for unit testing.
So for the entire time I’ve been developing iOS apps, I’ve been unit testing. I can say: this stuff works.
To spread “the stuff” further, I’ve written a book. It’s called iOS Unit Testing by Example: XCTest Tips and Techniques Using Swift. I’m positive it will help you, because I refer to the book myself.
You’ve got this. Let me know if you need help along the way.
Want to make sure you get notified when I release my next article or video? Then sign up below to join my list of Quality Coding Insiders. You’ll receive email notifications whenever I release new content. Plus, you’ll get access to the test-oriented code snippets I use every day!