Adding UI Testing to an existing iOS App
When Apple announced UI Testing at WWDC’15 we at Imgur got excited and wanted to add it as quickly as we could to the app. Of course if you’re making a new app you can just click a nice check box and get started with UI Testings.
If you already have an app that you want to add UI Tests to then follow these steps:
- Click on your project file
- Go to the list of targets
- Click the (+) plus at the bottom to add a new target
- Add the UI Testing Bundle from the Test category
- Confirm the “Target to be Tested” is your app
UI Testing Basics
There are 3 classes you should know about when UI Testing: XCUIApplication, XCUIElement, and XCUIElementQuery. A really basic test will consist of making an instance of XCUIApplication, creating a XCUIElementQuery to look for a XCUIElement such as a button, label, table, etc and then acting upon this element.
From the Apple talk on UI Testing in Xcode, they seemed to follow the following pattern for UI Tests. We follow the same pattern at Imgur.
- Create the element query
- Assert the element exists
- Interact with the element
Basics — Boiler Plate
When you added the testing bundle to your project Apple generated a bunch of boiler plate for you. We just slimmed down the boiler plate down and kept a reference to the app. This is the Base class we use for all of our tests.
We are using `launchArguments` so we can modify some states of the app during testing, and no — we’re not pulling a Volkswagen here. You can access these variables in your app checking `NSProcessInfo.processInfo().arguments`.
We just wanted to disable things like the tutorial and tooltips for this set of tests because we were just testing the happy path.
From our experiences so far the only way to pass data between the test process and the app process were the launch arguments and accessibility tags. The launch arguments are read only by the app and likewise the accessibility tags are read only by the tests.
The Basics 2 : The Basicing
Apple showed us some really good examples in their video, but we want to go past that. In the video Apple showed how to tap on a certain button if you know the string the button is showing. But in many apps not all buttons have static strings.
We still want to tap on buttons on the screen — but their label might be dynamic like the topic select button is in the Imgur App. The topic select button’s string displays the current topic — in this case “Design & Art”.
Apple provides different ways to identify certain elements inside your tests. The easiest way is to modify the `accessibilityIdentifier` property for that element in your Storyboard/Xib file in Interface Builder.
This particular button is not from a storyboard or xib so we’re gonna do everything programmatically. First we need to add an `accessibilityIdentifier` to the button.
Luckily this button is a subclass of UIButton, but if you are using a UILabel or UIImageView and treating it as a button in your app you should change the `accessibilityTraits` property of the element also.
Common Tasks
These are a few of the common tasks that came up while we were writing our UI Tests and our solutions to them.
Interacting with Alerts
We have an alert that pops up when a user signs out to confirm the action. So during UI testing we interact with this alert like this:
Autocorrect in Textviews
As you might have seen yet with typing text into a text view — Apple’s autocorrect likes to take over and modify the input the text. This happens even with really simple text like “Test Comment”. While this is a hacky solution it works reliably for inserting exact text into a text view:
Lazy Loaded Views
Another common task is testing lazily loaded views so we created a helper function for waiting till the view is loaded into the view hierarchy before moving on to the rest of the test.
References
- A good reference with getting started with UI Tests was written by mokacoding.
- A nice cheat sheet for UI testing by joemasilotti
- Some non Apple documentation for XCTest also by joemasilotti
