You are here

You are here

5 must-have open source tools for iOS testing

Thiago Lioy Senior iOS Developer, Concrete

Testing in iOS has improved considerably since its early days. It used to be challenging to run unit tests outside of Xcode, generate code coverage reports, and so on.

Apple eventually increased test support throughout its environment, making testers' lives easier, but things are still far from perfect. Fortunately, tools are available to help you test your code inside Apple's platform. I've used such tools in several projects, and achieved excellent results.

Here's how to incorporate them into your day-to-day code— and reap the benefits.


Quick is a behavior-driven development framework for Swift and Objective-C  inspired by RSpecSpecta, and Ginko.

It's built on top of XCTest, an Apple-provided framework that implements unit testing functions. There is nothing wrong with XCTest, but after a few days of working with it, you'll begin to notice how much repetition there is, and wonder why it is so verbose.

XCTest's issues include the following:

  • Tests must be declared as functions, starting with the word test.
  • No support for nested tests.
  • It's not possible to create different contexts.
  • No support for contextualized setups and teardowns.
  • Big test files look messy.

Quick addresses these problems. It has a cleaner syntax, support for arranging your tests in different contexts, contextualized setups and teardowns, and other things that make the process of writing tests a breeze.


Nimble is a matcher framework that comes bundled in the Quick project. A matcher framework makes it easier to write assertions. So instead of writing this:

XCTAssertEqual(1 + 1, 2, "expected one plus one to equal two")

You can write this:

expect(1 + 1).to(equal(2))


Figure: Using Nimble in Quick testsNimble-Snapshots

Nimble-Snapshots is a project with one goal: To make it trivial to work with Facebook’s iOS snapshot test cases. So is this Facebook project?

What it does?

A “snapshot test case” takes a configured UIView or CALayer and uses the renderInContext: method to get an image snapshot of its contents. It compares this snapshot to a "reference image" stored in your source code repository and fails the test if the two images don't match.


At Facebook we write a lot of UI code. As you might imagine, each type of feed story is rendered using a subclass of UIView. There are a lot of edge cases that we want to handle correctly:

  • What if there is more text than can fit in the space available?
  • What if an image doesn’t match the size of an image view?
  • What should the highlighted state look like?

It’s straightforward to test logic code, but less obvious how you should test views. You can do a lot of rectangle asserts, but these are hard to understand or visualize. Looking at an image diff shows you exactly what changed and how it will look to users.
—From the Facebook ios-snapshot-test-case Github page

In other words, it records screenshots of your app at a given time and then compares them with new screenshots of your app at the present moment; this can help you find changes in your code that have broken your app’s UI.

Fastlane and Slather

Fastlane is a set of tools that handle and automate several different needs of iOS developers. You can see other projects under the Fastlane umbrella on the "Meet the fastlane family" page.



No iOS pipeline would be complete without a mention of Fastlane. Here I focus on two tools: Slather and Scan. Scan is a command-line utility that gives a much better experience than the basic xcodebuilt tool. 

Figure: A Slather code coverage report

Slather is reads Xcode test data and generates code coverage reports from it. You can use these code coverage reports to help developers spot areas of the code that are not currently tested. The report can help you answer two questions:

  • What should I test next?
  • Is this class tested enough?

“Testing shows the presence, not the absence, of bugs. ”
— Edsger W. Dijkstra

For practical examples on how to use Fastlane, check out this repository of examples, including several community-contributed configurations.

KIF & KIF-Quick

The Keep it Functional (KIF) iOS integration test framework allows for easy automation of iOS apps by leveraging the accessibility attributes of iOS for people with visual disabilities.

KIF builds and performs the tests using a standard XCTest testing target. Testing is conducted synchronously in the main thread (running the run loop to force the passage of time), allowing for more complex logic and composition. This also allows KIF to take advantage of the Xcode Test Navigator, command-line build tools, and Bot test reports.

KIF-Quick is a bridge between the Keep It Functional and Quick frameworks. It lets you perform KIF actions using Quick syntax.

KIF lets you write more functional tests, simulating the behavior of the user inside your app. It enables you to click on buttons, scroll, swipe, and so on. In that sense, it is like Apple UI Test case. The difference is that you can still mock or modify the code from the test as you would in a unit test.

In addition, you can load any screen without needing to navigate all the way to it. That means you can load the confirmation screen in a checkout flow (providing all the inputs for it as mock objects) and check the behavior without running your entire checkout flow.

Tools to make you a better developer

Testing is not something inherently tricky by itself. The problem is that it requires discipline, a shift in your mindset, and lots of practice. All of the tools mentioned above will help you become a better developer.

Once you incorporate this set of practices and develop a testing mindset, your code will become more reliable, decoupled, and flexible. But you must. of course, play with the tools to reap the benefits.

“An ounce of practice is generally worth more than a ton of theory.”
― Ernst F. Schumacher



Keep learning

Read more articles about: App Dev & TestingTesting