iOS developers generally don’t unit test. So why then do they as a community seem to enjoy a reputation for quality?
No unit tests. No continuous integration. No TDD.
That pretty much summarizes my last project. It was my first paying iOS gig, and not only did we not apply these cherished practices, we shipped a high quality product.
This really bugged me.
I had always thought unit tests were essential. But this experience with iOS seemed to challenge some deeply cherished assumptions I had developed over the years about writing software, and led me to ask myself some very uncomfortable questions.
Was I regressing in my development practices?
Were unit tests not essential?
Was there something different about iOS development?
And how did the iOS community ship quality products without unit tests at their core?
These questions kept me up at night, and led to the soul-searching I’m sharing in this article.
Ten years ago I used to debate people on the merits of unit testing. Not any more. Unit testing has become such a common practice that you’d struggle to find a modern development platform that doesn’t have some sort of automated testing framework.
And why not? The benefits are obvious. You can release, change, and refactor your code with confidence. You save a ton on regression testing. And the feeling of security that comes from knowing you have a suite of automated unit tests backing your every change is undeniable.
So imagine my surprise when I entered a community responsible for some of the world’s most loved mobile applications, only to discover that they don’t unit test. Even more deeply disturbing, they seem to be getting away with it!
What’s Different about iOS?
While I won’t say developing apps on iOS is easier, there are definitely a few things that iOS developers have going for them.
1. Smaller screen size.
You can’t fit a lot on a mobile phone screen—there just isn’t a lot of room. The apps also tend to be smaller (many don’t even have a backend). This, when combined with a culture of minimalism, dramatically simplifies things in terms of code and data. There is simply less of both.
2. No legacy.
Mobile apps are so new, iOS developers typically aren’t burdened with 100,000 lines of legacy code the way enterprise developers sometimes are. This lets them start from scratch unencumbered.
3. One language.
You can build an iOS application knowing only one language: Objective-C. The typical web developers needs no fewer than four or five languages to do anything other than static HTML.
4. A mature platform.
A lot of the heavy lifting is done for you in iOS. If you need to do something with photos, music, or Facebook, it’s there. You just plug in.
5. Very visual.
This was probably the biggest difference for me coming from the enterprise. Instead of spending days wading through layers of architecture (mocking and unit testing every step of the way), iOS developers have almost no layers of architecture. They spend almost all their time at the UI layer.
That means the nature of the code they write is often visual. The only way to see if it works is to fire up the simulator and try it out.
As interesting as these differences are, however, they still don’t tell the whole story. If they did, every mobile platform would enjoy this higher level of quality. Nope, there’s something else going on. Something bigger.
When you do something for a long time, it’s easy to forget what people in your field once did without.
Architects used to work with slide rules.
Seafarers used to navigate by the stars.
Artists used to work solely with their bare hands.
Programmers used to program without unit tests (often at a much higher quality they you see today).
And yet in all these fields, practitioners were able to achieve what we today, with all our modern tools, would admit was a high level of quality in their work. So how did they do it? What was their secret?
These people simply cared more about their craft, and what they were doing, than their contemporaries. They “out cared” the competition. And that is what I see in the iOS community.
They care more about the art.
They care a lot about the exact wording and spacing of text on buttons.
They care a lot about speed and performance.
And they care a ton about affordances (like remembering where in the scroll list a user was when they put the application in the background).
Apple works very hard to make sure every developer in their ecosystem cares, and they give them the tools so they have no excuse not to.
They walk them painstakingly through the importance of creating beautiful art.
They share (and enforce) human interface guidelines for mobile application development.
They curate and block apps that don’t meet certain quality standards.
And their former CEO was known for calling people up in the middle of the night to tweak a color or a logo.
It’s in the community’s DNA.
These guys care. They care like artists care. And—I’m just citing my own experience here—the same can’t be said for other platforms I have been a part of.
What Does This Have to Do with Unit Tests?
Absolutely nothing. And that’s my point.
unit tests != quality
What leads to quality is something much bigger—more than a collection of software engineering techniques or a collection of practices.
When I entered this community I was under the false impression that if you didn’t write software the way I did, you must be doing it wrong.
Instead I discovered a community that cared more about quality than I did, and I learned that I still had a lot to learn about crafting a quality experience.
That’s what this whole things has taught me. It’s not about the practices. It’s about the spirit and intent behind them, and how they are applied. Used when applicable. Quickly abandoned when not.
Are unit tests an invaluable tool for writing great software? Hell yes.
Am I going to produce a poor product if I can’t unit test? Hell no.
And that is what this experience taught me. I need to be more than a collection of practices.
To keep growing sometimes we need to challenge our most cherished assumptions. It doesn’t always feel good, but that’s how we grow, gain experience, and turn knowledge into wisdom.
The second you think you’ve got it all figured out, you are dead.
If you want to see how far down the rabbit hole this whole discussion on quality can go, I suggest picking up a copy of Zen and the Art of Motorcycle Maintenance. It’s not an easy read. But it may change your life.
Oh yeah, and keep unit testing.
Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.