Test-driven development: Does it work for iOS apps?
Short answer: Sure! Here‘s an example:
Yeah, that‘s a really old image, and no, you can't find this on the App Store anymore. But this was an app published by eBay. Here's the unit test coverage:
It was written almost entirely using TDD. Sometimes tests weren't written first (especially the code written by someone 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:
- Writing tests before writing production code shaped the interfaces, leading to better design.
- High test coverage let me refactor when the code needed it, leading to cleaner implementation.
Better design. Cleaner implementation. Think about it.
A bit more about that 92%:
- I left third-party code out of the coverage calculation. This goes for open source (such as JSON parsing) and internal code used in other eBay apps. You don't need to write unit tests for code you're not going to change.
- At one point, the coverage was as high as 95%. I felt quite good about that. But when I met Jens Nerup in person and shared this number, he asked me a challenging question: "What about the remaining 5%?" 100% coverage may not be attainable, but don't stop at an arbitrary number.
- Having high test coverage doesn't mean bugs weren't discovered. There weren't very many, but preventing bugs isn't a TDD goal. It's more like a side effect. Again, the goal is shaping interfaces and enabling bold refactoring. Design + implementation.
Preventing bugs isn't a TDD goal. It's more like a side effect.
iOS test-driven development isn’t a pipe dream. I continue to use TDD, these days on an app for a Fortune 100 company. It’s my daily reality, and it can become yours.
Question: Have you used TDD to develop your apps, or any part of your apps? What were the ups & downs you experienced? Leave a comment below.