iOS Unit Testing Example Techniques Book Details
Title: iOS Unit Testing Example Techniques
Author: Jon Reid
No. of pages: 350
Format: PDF, EPUB
Preface iOS Unit Testing Example Techniques
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.”
iOS Unit Testing by Example
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.
How This iOS Unit Testing Example Techniques Book Is Organized
This book explores its ideas using coding examples. Each chapter has a section describing how to make “a place to play.” One can learn things by reading, but learning by doing is more effective. If you take the trouble to set up each project, trying the changes and experiments, your learning will go deeper.
I’ve organized the iOS Unit Testing Example Techniques book into three parts: Foundations, iOS Testing Tips and Techniques, and Using Your New Power. Here’s a quick summary of each part.
Part I: Foundations
The first part covers the foundations of using XCTest with iOS apps. The first three chapters cover XCTest. We start with test assertions, move on to man- aging test suites, and then how to use code coverage to reveal holes.
The next two chapters get into iOS apps. We explore how the app launch sequence may interfere with test isolation. Then we’ll see how to load view controllers from test code. This varies, depending on whether a view controller is storyboard-based, XIB-based, or code-based.
The last chapter of Part I examines dependencies that make testing difficult. Managing dependencies and replacing them is a foundational skill for unit testing. We’ll see what options are available to us in the Swift programming language.
Part II: iOS Testing Tips and Techniques
The second part is a grab bag of techniques for testing iOS specifics. You can jump around these chapters more freely. You can follow the cross-references that appear where the chapters build on each other.
We start with the basics of making sure outlets are connected, and how to tap buttons. This alone opens up a world of testing possibilities.
Then we’ll see how to test presented views. This includes alerts and navigation from one view controller to the next.
Things become more challenging as we get into persistent data and networking. These topics lead us into test doubles. We’ll see how to use fakes, spies, and mocks.
iOS Unit Testing by Example
For examples of more complicated UI elements, we’ll examine text fields and table views. They’ll take us into the topic of how to test delegate methods. Finally, we’ll see how to test view appearance using snapshot tests.
Part III: Using Your New Power
The last part demonstrates what a solid set of unit tests empowers you to do.
Chapters 17, 18, and 19 focus on refactoring. Contrary to common usage, the word “refactoring” doesn’t mean rewriting. Instead, it’s a structured disci- pline of moving in small, verified steps to change the design of code.
Unlike most of the iOS Unit Testing Example Techniques book, the examples in these chapters build on each other, so do them in order. In Chapter 17, we create a working view controller, bring it under test, and begin refactoring. We do this with the most common refactoring moves. These moves belong in your tool belt.
To illustrate how much we can change code design by applying small steps, the UI pattern starts from model-view-controller (MVC). In Chapter 18, we refactor our way from MVC to model-view-view-model (MVVM). Then in Chapter 19, we transform the view controller to use model-view-presenter (MVP). The point isn’t to promote any particular UI pattern but rather to show how refactoring makes it possible to do large transformations.
Finally in the last chapter, we’ll do test-driven development. This code example is unrelated to the earlier chapters. TDD combines unit testing and refactoring with emergent design. Having covered unit testing and refactoring, you’ll be most of the way there by the time you start this chapter.
Disclaimer: No SwiftUI Support
SwiftUI is Apple’s new declarative UI paradigm. They unveiled their first version of it at WWDC 2019. Since there’s a lot of excitement around this paradigm, you may wonder why it’s not covered in this book.
The main difficulty is that as I write this, SwiftUI is still quite new. This makes it a moving target, which Apple will iterate on over the next few years. Not only that, but I simply haven’t used it yet.
And Apple has initially focused on making SwiftUI work and not on making it testable. In the first round, there don’t seem to be any clean ways of testing the behavior or data flow of SwiftUI code. Some folks in the iOS developer commu- nity are coming up with their own patterns and helpers as workarounds. Will we come to agree on any standards for unit testing SwiftUI? My guess is that this will happen when Apple decides to put their weight into the problem.
So this book uses the well-established declarative paradigm of UIKit. As you create new projects for the worked examples, be sure to select “Storyboard” as the user interface, not “SwiftUI.”
The source code shown in this book can be found under the “Source code” link on the Pragmatic Bookshelf website.3 You can also help improve this book by submitting errata, from typos to content suggestions.
First, I must thank my wife, Kay Reid. She’s been my constant “go for it” voice, encouraging me to grow my initial teaching into a iOS Unit Testing Example Techniques book and a consultancy.
Daniel Steinberg was the first person who advised me to write a book. Daniel, I owe you a drink.
I also want to thank Graham Lee. He was the first “voice in the wilderness” with his book Test-Driven iOS Development [Lee12]. Thank you for that book, for being an encouraging friend, and for writing the foreword to this book. Who else but Graham would turn a technical foreword into a reflection spanning thousands of years?
I rely on feedback loops for software development, but had no idea that writing a book worked in the same way. I’m deeply grateful to the technical reviewers whose feedback made this book so much better. The reviewers were Andrew Ebling, Fred Brown, Janie Larson, Josh Justice, Liz Marley, and Mark Dalrymple.
Besides the “official” reviewers who worked with my editor, many of you emailed me directly. Thank you for your corrections and suggestions. I espe- cially want to thank Simon Rofe, who struggled with me to find a way to unit test storyboard segues. Cheers, mate.
Finally, I want to thank all the students at my workshops on test-driven devel- opment for iOS. Several innovations came from those discussions, and some were discovered by the students. Every time I teach, I learn something new.