An Introduction to Automating iOS Mobile Apps with XCUITest Framework
XCUITest is Apple’s native UI testing framework that is built on top of the XCTest framework.
It supports Swift and Objective-C programming languages. It tests the UI layer and interacts with the mobile app the way a real user would. It also compliments the Unit testing that’s done using XCTest. This framework covers the broader aspects of any iOS mobile app functionality and is effective for integration testing.
UIAutomation framework that was previously used for automating iOS applications has been deprecated by Apple from XCode8. Xcode now comes with XCUITest framework along with XCTest framework.
Pros and Cons:
Pros of this framework include the following,
- Very fast and easy to maintain
- Can easily be integrated with CI
- Reliability — No more flakiness in tests
- Apple TvOS supported
- Apple’s native language support
- Gives confidence during frequent Mobile App releases
- Reduces time to market
- It doesn’t support Cross-Platform
- Limited programming language support
Comparing XCUITest with Appium:
It’s important to compare both frameworks because users prefer Appium for Mobile Automation because of its various features.
- When it comes to language support: XCUITest supports Objective C/Swift whereas Appium supports Java, Objective C, J, PHP, Python, Ruby, C# & Perl.
- Record and Playback options: XCUITest records using Accessibility identifiers and XCUIElement Query and it is much faster than Appium which records using Xpath.
- When it comes to script design, it is easy to add accessibility id in the framework when the developers don’t add it whereas in Appium we can only use objects that are available and those object identifiers cannot be modified using the framework.
- Both frameworks support Continuous Integration.
- We have inbuilt “Test Report” in the XCUITest framework whereas Appium requires customization
- When it comes to Execution time, XCUITest is 12 times faster than Appium.
Some of the basic XCUITest APIs are listed below with their purposes.
XCUIApplication: A proxy for an application under test that can be launched and terminated.
XCUIElement: An Application’s UI Element.
XCUIElementQuery: A query for locating UI elements.
Framework Design Patterns Involved:
Majorly two design patterns are involved over here namely,
- Fluent Page Object Model
- Screenplay Patterns
Page Object Model uses a fluent interface (implementation of an object-oriented API that aims to provide the most readable code). It follows method chaining.
The screenplay pattern is formerly known as Journey Pattern. It is an approach for writing high-quality automated acceptance tests and is similar to a Behaviour Driven Framework.
Xcode Setup for User Interface testing:
If you need to set up an iOS UI Testing project, below are the steps for it,
1. Open the Xcode project.
2. Go to File — New — Target.
3. Select “iOS UI testing bundle” and proceed further.
4. In the screen, Choose options for your new target — Select your Team and Target to be tested.
5. Then Click on the Finish button to create a new test target.
6. Create a test file in the location of your Project navigator where you would want it to be placed.
7. Right-click on it and select New File.
8. Select UI Test Case Class and click the Next button.
9. In the Choose options for your new file window, provide class name and click the Next button.
10. Click Create button.
11. You have now created a UI test class with setUp and tearDown methods.
One thing to keep in mind is that the method Name should start with the word “test”.
Creating Script using UI Recorder:
UI Recorder is used to record the flow of the application and generate scripts along with object elements. You can do the recording following the steps given below,
- Go to Test Navigator
- Click on the test function for recording
- Click on the UI Recorder button
- Execute the scenario in a real device /simulator
Once that is done, you are ready with the script. But the script has only the actions that we have recorded. So in order to validate elements throughout the scenario, we need to include Assertions.
Inspecting Elements Using Accessibility Inspector:
The better approach to inspect elements is by using Accessibility inspector since UI Recorder is good for simple cases but to create scripts for complex scenarios, the Inspector is the best approach. Below is how you open the inspector.
- Open Developer Tool -> Accessibility inspector
- Click on the Start Inspection button
- Start the object inspection
One approach to get the screen to debug description is to print the hierarchy in Xcode console like below,
Execution of scripts:
There are two ways to run your tests,
1. In Xcode, navigate to Product -> Test, by doing this it will run all the tests in the project including Unit tests which are maintained as part of the same project.
2. But to run only the UI tests, navigate to the Test Navigator and click on Play button near the UI tests that you want to run.
3. There will be a situation where only few test methods should be executed so in that case you can go to the test class and click on the diamond icon displayed near the test method.
To make the test more stable and reliable it is good to include as many validation assertions as you can. Some of them are listed below,
To validate the if a Sign In button exists,
- let SignInButton = app.staticTexts[“SignIn”]
- XCTAssertEqual(SignInButton.exists, true)
To validate the error message displayed,
- let ErrorMessage = app.staticTexts[“Password must be more than 4 characters”]
- XCTAssertEqual(ErrorMessage. label, “Password must be more than 4 characters”)
To view the Test Results, go to the Test navigator. If you test case has failed, then those would be listed with a red exclamation mark. Right click on your test and select Jump to report. Upon expanding views, you will be lead to the point where the test had failed.
Author: Sangeetha M