At WWDC 2017, there was an amazing talk on engineering for testability which focuses on the importance of quality of test code along with app code. The talk introduced various way we can improve testability of apps by writing great test code. The most important bit was a second part where the tips on improving the scalability of UI tests have been shared. In this post, we will see what are those tips shared by Apple engineers. Remember, this is not just copy paste of the talk presented at WWDC, this post also has some real life examples with demo project on Github Scalable-XCUITest to prove those points.
WTF is Scalable Test Code?
The test code is as important as app code even it’s not being executed in the production. We should definitely make our app testable but also put some efforts to make test code more scalable. So, the benefits of scalable test code are
- Run our test faster
- Make our tests more readable even for non-technical people
- Organise test code in better way to avoid duplication
- Make it easy to add new test cases
Example App
Let’s explore some of the techniques shared by Apple engineers to make the test code scalable with example application Scalable-XCUITest, this app has buttons with 6 different colours which are RED, GREEN, BLUE, BLACK, GRAY and YELLOW. This is very simple app but imagine that we have to test few things like
- Tapping on all colours
- Just tap on RBG colours
- tap on non-RBG colours.
The non-scalable UI test for this looks something like this:
1 2 3 4 5 6 7 8 |
func testTapAllColorNonScalable() { XCUIApplication().buttons["RED"].tap() XCUIApplication().buttons["BLUE"].tap() XCUIApplication().buttons["GREEN"].tap() XCUIApplication().buttons["BLACK"].tap() XCUIApplication().buttons["YELLOW"].tap() XCUIApplication().buttons["GRAY"].tap() } |
Again to test the RGB and non-RGB values we have to almost repeat the same things. You can have a look at the test class Non_Scalable_XCUITestUITests.swift here and guess how messy it is. We can definitely make it better by using the techniques described in the talk.
Tips for Writing Scalable XCUITest
There are some tips shared to make tests scalable, maintainable and faster by using some common object oriented principles like abstraction and encapsulation. Let’s go through some of the techniques
Abstract XCUIElement Query
If there is a situation where we are using XCUIElement query multiple time, store it in a variable. In the example above, we are tapping button 6 time but only thing changing is the colour of the button. We can easily wrap this into the method.
1 2 3 |
func tapButton(_ color: String) { XCUIApplication().buttons[color].tap() } |
Now that, we can just pass the name of the colour to the method. We can go even further and store each element of the colour in an array and loop through them.
1 2 3 4 5 6 |
func testTapAllColor() { let colors = ["RED", "BLUE", "BLACK", "GREEN", "GRAY", "YELLOW"] for color in colors { tapButton(color) } } |
Now that test looks more maintainable and readable.
Create Objects and Utility Function
We can go further and create a Colors class and store all the data inside the class as static members. We can access those members from the tests.
1 2 3 4 5 6 |
class Colors { static let colors = ["RED", "BLUE", "BLACK", "GREEN", "GRAY", "YELLOW"] static func tapButton(_ color: String) { XCUIApplication().buttons[color].tap() } } |
We can access those members from the tests. Our test will look like this
1 2 3 4 5 |
func testTapAllColor() { for color in Colors.colors { Colors.tapButton(color) } } |
Encapsulate Common Testing Workflows
We now have to test for the specific colours. We can also define Swift enumerations for RGB and non-RGB colour values.
1 2 3 4 5 6 7 8 9 10 11 |
enum RBG: String { case red = "RED" case blue = "BLUE" case green = "GREEN" } enum Non_RBG: String { case black = "BLACK" case gray = "GRAY" case yellow = "YELLOW" } |
We can access the raw values of the RGB and non-RGB colours from anywhere. We can now add more utility functions to our Colours class.
1 2 3 4 5 6 7 |
static func useRGB(_ rgb: RBG) { XCUIApplication().buttons[rgb.rawValue].tap() } static func useNonRGB(_ nonRgb: Non_RBG) { XCUIApplication().buttons[nonRgb.rawValue].tap() } |
We can call those configuration utility methods inside the test.
1 2 3 4 5 |
func testRBGBlueButton() { Colors.useRGB(.blue) Colors.useRGB(.red) Colors.useRGB(.green) } |
Now that our test to tap on RBG and non-RBG button makes more readable and extendable.
Sprinkle XCTActivities for better test reporting
Activities are the way to organise those actions into the group by giving a meaningful name so XCTest result will use that activity name in the result to make it more readable. You can read more about activities on Apple official documentations here. In our example, we can sprinkle an XCTActivities and make our more readable in the test reports.
1 2 3 4 5 6 7 |
func testRBGBlueButton() { XCTContext.runActivity(named: "Check only RGB Colors") { _ in Colors.useRGB(.blue) Colors.useRGB(.red) Colors.useRGB(.green) } } |
You can see the entire test class Scalable_XCUITestUITests.swift on GitHub here.
Try Yourself
You can try those tips yourself with example project on Github Scalable-XCUITest with Xcode 9.
1 2 3 |
$ git clone https://github.com/Shashikant86/Scalable-XCUItest $ cd Scalable-XCUItest $ open Scalable-XCUITest.xcodeproj |
Hope you are already using the Swift abstractions and encapsulations to make XCUITests more scalable and maintainable, what are your experiences with XCUITests so far? Share in the comments below!