iOS UI Testing with KIF

Learn how to do iOS UI testing with KIF.

Users expect a high level of polish from iOS apps, so it’s up to you to design, develop and test your apps to meet ever-rising expectations. Think about it for just a moment: How much time have you poured into conducting basic manual user interface testing? You know the drill…launching your app from Xcode, and incessantly tapping the same series of buttons to make sure no regressions slipped into your design. Surely, there are other things you’d rather do?

Instead, consider that the enhanced test UI in Xcode 5 and continuous integration support in OS X Server demonstrate Apple’s commitment to provide developers the best tools. That’s great, you might say, but how do you automate testing simple user actions, like ensuring a double-tap or swipe at the right spot brings up the correct view? Even test scripts and bots don’t have capacitive touch fingers to swipe across the screen…or…do they?

In this tutorial, you’ll learn all about KIF (“Keep it Functional”), an open-source user interface testing framework. With KIF, and by leveraging the Accessibility APIs in iOS, you’ll be able to write tests that simulate user input, like touches, swipes and text entry. These tests give your apps an automated, real-world user interface workout, and help keep your mind at ease so you can just focus on developing that killer app – not spending half a lifetime on UI testing.

Let’s get testing!

Getting Started

The sample project is a timer app called Solanum (named after the tomato plant species) based on the Pomodoro time-boxing method. Here’s how it works: you work for a defined number of minutes, take a break, then repeat. After several of these cycles, you take a longer break. The app is a just a simple timer that keeps track of time periods. Feel free to use the app afterwards to help make you more productive during your own development!

Download and unzip the starter project archive here. Note that KIF is a separate project, and its role is to build a library for Solanum’s test target. You’ll need to double-click solanum.xcworkspace to open the project in Xcode rather than solanum.xcodeproj. Look for two projects to open in the in the project navigator, it should like the example below.

Set the app target to solanum, and select either the 3.5-inch or 4-inch iPhone Simulator target. Don’t use the 64-bit build; at the time of writing this tutorial KIF didn’t appear to be fully compatible. Build and run the app. Look around, then switch to the Settings tab.

The app has a debug mode that accelerates time, so you can set a 20-minute timer and it will help with testing by ticking by in 10 seconds. This is just to aid testing the app. You wouldn’t want each test run to take 20 minutes!

Turn on Debug Mode switch to speed up the timer. Next, tap the Clear History button, and then tap Clear on the confirmation alert view. These steps will ensure you’re starting out in a clean, test-friendly environment. Return to Xcode and stop the app.

Pre-Test Actions

In the Project Navigator, expand the solanum project. Right-click the UI Tests folder and click New File… to add your first test case.

Select iOS\Cocoa Touch\Objective-C class and click Next. Name the class UITests and make it a subclass of KIFTestCase.

Click Next and make sure the files are be added to the UI Tests target, not the solanum target. Finally, click Create on the following screen to save the files.

KIFTestCase is a subclass of SenTestCase. That means you have most of the standard OCUnit testing methods and mechanisms available, in case you’re already familiar with unit testing.

Open UITests.m and add the following method after the @implementation line:

- (void)beforeAll {
  [tester tapViewWithAccessibilityLabel:@"Settings"];

  [tester setOn:YES forSwitchWithAccessibilityLabel:@"Debug Mode"];

  [tester tapViewWithAccessibilityLabel:@"Clear History"];
  [tester tapViewWithAccessibilityLabel:@"Clear"];
}

beforeAll is a special method that is called exactly once, before all of the tests run. You can set up any instance variables or initial conditions for the rest of your tests here.

The tester object is a special shortcut to an instance of the KIFUITestActor class. That class includes the methods that will simulate user activity, including tapping and swiping on views.

tapViewWithAccessibilityLabel: might be the most common test action method. As the name suggests, it simulates tapping the view with the given accessibility label. In most cases, such as for buttons, the accessibility label matches the visible text label. If not, as you’ll see in the next section, you’ll need to set the accessibility label manually.

Some controls, such as UISwitch, are more complicated and need more than just simple taps. KIF provides a specific setOn:forSwitchWithAccessibilityLabel: method to change the state of a switch.

In summary, this method has four steps for the test actor:

• Tap the “Settings” tab bar button.
• Set the “Debug Mode” switch to its “On” state.
• Tap the “Clear History” button.
• Tap the “Clear” button on the UIAlertView.

Do these steps seem familiar? They should be! They’re what you did manually in the previous section!

Run the tests by going to Product\Test or hitting Command-U on the keyboard. You should see the app launch; then you’ll see KIF take over, automatically enable debug mode and clear the history.

If you have notifications enabled, Xcode will also tell you the test status:

Sometimes the test runner, or KIF, can get a little finicky and will refuse to run your tests, in which case you’ll just see a blank simulator screen. If this happens:

• Clean the project (Product\Clean)
• Build and run
• Wait for the app to launch
• Stop the app in Xcode

This process ensures the Simulator is running and that you’re working with the latest build. After going through the above steps, try running the tests again. The problems should be gone.

If you continue to have trouble, check out the KIF troubleshooting steps.

Now that you have a pre-test action in beforeAll, it’s time to add your first test!