In early June, Apple released a new UI testing tool in WWDC 2015. I’ve tried this interesting tool in some of our internal projects during the past three weeks, and I’ve discovered some pros and cons along the way. I share my experiences below:
What’s my environment:
OS X Yosemite 10.10.3
Xcode 7.0 beta 2 (pre-release version)
Swift 2.0 (pre-release version)
iPhone 6 Simulator iOS 9.0 (pre-release version)
The pros of Apple’s new UI testing tool:
1. Build-in
Compared with KIF (aka: Keep It Functional – an iOS Functional Testing Framework), selenium (which added iOS testing support recently) and calabash, Apple’s UI testing tool requires no additional tools, libraries or other programming language support. To enable the UI testing feature, remember to check the scheme if the tests are enabled.
2. Easy-to-use
As Apple demonstrated in the company’s WWDC video, this is one of the easiest UI testing tools I’ve ever used. All you need to do is to create a new scheme, and simply click the “Record” button; then you are ready to write UI testing code automatically.
3. Easy-to-maintain
This new UI testing tool creates and writes UI testing script in the project directly (just in a different scheme), so we can use any source control tools to maintain the test code as well as our main developing code. This makes life much easier compared with those tools that need to save the test script in an additional file.
The cons of Apple’s new UI testing tool (so far):
1. Hard to locate some specific UI element correctly
If you create a UI collection view in the storyboard and add a custom cell then create several images and labels inside this custom cell in a separated xib (a common way to create a custom view), then it could be a nightmare for Apple’s UI testing tools. Here is what I received for a single image view:
While in KIF (another tool that can do iOS UI testing, which I mentioned above) , I can simply add an accessibility label for this image and then ask UI to locate it like this:
This is much simpler and easier, right?
2. Failed-for-element-inside-accessibility-view
For some navigation tests, we need to click a button, and then see if the next view is what we want. In that case, one of my own solutions is to add an accessibility label in the correct view and add a function to check if the label pops out in KIF:
For example, if I want to click the “back” button to navigate to the main view, and then click another button inside the main view, the code in KIF would be like this:
But for the new Apple UI testing tool, if there is an accessibility label in the “main view”, then all the elements inside this view will be inaccessible to detect later.
Apple’s UI tool can only recognize one element named “MainView”
3. Lack-of-some-highly-used-function
Sometimes the app may be lagging for a while, so one of the most commonly used functions in UI testing is “wait for some time.” In the KIF, I can simply use a function like:
This would ask the robot to wait 1 sec then continue to do UI testing – a useful method if the app is a big one. Unfortunately, I haven’t find any similar method in the new Apple UI testing so far (Xcode 7 beta 2 pre-released version).
Conclusion
Apple did a great job with the new testing tool. This new UI testing tool is one of the most interesting and easy-to-use tools I ever used so far, but there’s still a lot of room for Apple to improve the tool. Before the formal version is released, I recommend using other third-party testing tools such as KIF, selenium or calabash while doing business.
