The maturity of mobile UI automation frameworks has lagged behind web automation frameworks, but Apple’s introduction of UI automation to the XCTest framework in XCode 7 represents a major step forward. We now have the UI recorder, a tool that enables us to quickly identify elements in our application and generate working tests. Test automation paradise, right? Unfortunately, tools like the UI recorder can produce long scripts full of repetitive code that is neither well factored nor maintainable. Although you can apply to mobile the Page Object design pattern, popularized in web automation, there is a lack of out-of-the-box frameworks to help write these objects. Join Jason Hagglund as he demonstrates how we can easily create our own screen objects—classes that model the application’s UI and encapsulate element identification, common actions, and complex assertions. Jason applies object-oriented design concepts—including inheritance, overriding, and Swift protocols—that result in a robust framework that makes producing maintainable tests friendly and easy for both testers and developers.

1. Scalable and Collaborative UI
Test Automation in Swift
Jason Hagglund
Staff Software Eng - Test, The Climate Corporation
https://github.com/TheMetalCode
Twitter - @jhagglund
Where are we going?
● Why bother with UI test automation?
● XCTest API and UI Elements
● Identifying UI Elements (Storyboard and Programmatically)
● Stop Relying on the Recorder and Automate Predictively
● Write Better UI Automation Code with Screen Objects
● Extras
● Questions
2

2. Why bother with UI test
automation?
Because this talk would be really lame if UI tests weren’t important or
useful.
It’s All About the Pyramid
4
http://martinfowler.com/bliki/TestPyramid.html

3. Why UI Test Automation Efforts Sometimes Fail
if effortToMaintain > valueAdded {
notWorthIt();
}
5
The iOS UI and the XCTest API
Looking at the structure of what we’re testing and the code that gives us
the access to the UI.

4. Our Toolbox for iOS UI Automation
● XCode 7+
● XCTest (supports UI testing as of
XCode 7, iOS 9+)
● Swift
7
● On the web: http://masilotti.com/xctest-
documentation/index.html
● Build it locally: https://github.
com/joemasilotti/XCTest-Documentation
Regarding XCTest Documentation...
8

5. What is XCTest?
9
A build target that targets your application’s build target. Say that 10x fast.
Your XCTest Bread and Butter
● XCUIApplication
○ This class models the application itself and has two functions:
launch and terminate.
● XCUIElement
○ This class models a UI element contained within the
application.
● XCUIElementQuery
○ This class models a search for an element.
10

6. UI Test Recorder: An Exploration Tool
11
Identify UI Elements from the
Storyboard
The least painful way to uniquely tag our UI elements for automation
purposes

7. 13
Identity Inspector and Accessibility Are Your Friends Accessibility Identifier > Accessibility Label
14
● Lest we forget: the primary purpose of Accessibility-
enabled elements is to allow your app to be used in
accessibility mode on the device.
● Accessibility Labels are what the end user would
actually see/hear in order to interact with your app.
● Accessibility Identifiers don’t leave a mark.

8. Accessibility Identifier > Accessibility Label
Identify UI Elements
Programmatically
Our first encounter with the power of Swift Protocols

9. About Those Pesky Dynamically Generated Elements...
● Protocol (similar to an Interface in Java): a collection of
properties, methods, etc., that encapsulate common
behavior that you want otherwise unrelated classes to
share.
● UIKit elements conform to the
UIAccessibilityIdentification protocol, which has exactly
one contract requirement: accessibilityIdentifier.
17
Let’s ID Some Table Cells Programmatically
18

10. Stop Recording and Write
Predictive UI Tests
The recorder is an exploration tool, not a testing tool.
A Revelation from Morpheus
20

11. No Really, It’s This Easy (In Many Cases)
var someButton = app.buttons[“accessibilityIdentifier”]
“app” = instance of XCUIApplication
“buttons” = just one of many XCUIElementTypeQueryProvider methods (hey
look, another Protocol!)
“accessibilityIdentifier” = the accessibility identifier you have configured for
that element
21
Why This Matters
● Kill more bugs faster! (enables TDD-like
practices)
● Plus, just looks cleaner. Remember that ugly
recorder-generated code earlier?
22

12. Write Better UI Automation
with Screen Objects
Your tests are software. Code like it.
Which Would You Rather Maintain?
24

13. Which Would You Rather Maintain?
25
Morpheus Says Take Pride in Your Test Automation
Code!
26

14. Loadable: All Screen Objects Can Tell if They’re
allLoaded()
27
Encapsulate UI Element Identification
28

15. Encapsulate Actions
29
Encapsulate Complex Assertions
30

16. Behold! Clean, Easy-to-Write UI Tests!
31
Extras
For more advanced test automation needs

17. Asynchronous Test Expectations
● Doable, but kinda ugly. DRY and write methods that
wait on elements once.
● https://gist.github.
com/kcharwood/0a57d7a207aba1d578da
● http://masilotti.com/xctest-helpers/
33
Code Coverage for UI Tests
34

18. Cucumber/Gherkin Goodness!
● Yes, really, somebody is finally doing this!
● Integrates with both KIF and XCTest
● https://github.com/Ahmed-Ali/Cucumberish
35
Conclusion
Some stuff I hope you took away from all this that will stick.

19. Scalable and Collaborative
● Scalable: leverages the well-worn patterns and practices
of object-oriented programming to make producing UI
tests as easy and DRY as possible.
● Collaborative: a first class citizen that lives in the
application code and conforms to the same high-quality
standards.
● Devs + Testers can make awesome apps together
37
Email - hagglundized@gmail.com
Twitter - @jhagglund
Code - https://github.com/TheMetalCode/ios-ui-automation-demo
Thank you! Any Questions?