Transpire TechBlog
Published in

Transpire TechBlog

Learning to Code to Become a Better Tester

By Jaswanth Manigundan, Lead Software Engineer in Test, Transpire


Vodafone Foundation’s DreamLab has been through a major refactoring and performance improvement phase over the last few months in preparation for a global rollout — the app added 14 new regions to its suite.

As a part of this, the Android app was refactored to conform to the latest best practices, the backend was performance tested through a string of updates, and the iOS app changed all its screens to SwiftUI.

In this article, I would like to share my experience working on the iOS app and some of the challenges of testing it, with an emphasis on UI testing.

The all new SwiftUI

SwiftUI was introduced during last year’s WWDC and has changed the way iOS apps are written. Therefore, migrating to SwiftUI meant the DreamLab’s UI needed to be rewritten.

We also planned to rewrite our UI tests to make sure they covered every part of the app — our visual snapshot tests covered most of the UI components in a very thorough way, so we didn’t want the UI tests to have redundant test cases.

But when I started writing UI tests for the new screens, I struggled a bit since I was used to the old storyboard views. With SwiftUI, I had to learn how to add accessibility ID to the right components so that I could make use of them when writing XCUI tests.

I tried randomly searching for concepts in SwiftUI when the need arose, but that didn’t help me. I found it really time consuming to do the simplest things. Therefore, I thought the best approach was to understand SwiftUI from the ground up. And the best way to do that, in my opinion, was to write an app using SwiftUI.

Building a sample app — BitWall

Every time there is a need for me to come up with sample apps, I tend to write apps that would be useful for myself or my team on a daily basis. I chose to write a client app for since bitrise didn’t have a simpler way to download builds quickly. I thought I could solve two problems at once.

First, I completed the SwiftUI essentials course from Apple one weekend. It was really interesting, since being a professional (ex-)Android developer, this felt more similar to how Android works.

Then I jumped into Bitrise’s API and came up with a client app.

Some of my Learnings From a Testing Perspective

Now that I know how SwiftUI works and having written an app using it, I was able to come up with useful points that would help me write my UI tests better.

BitWall app in action

#1 — The way SwiftUI handles accessibility ID

The first thing that has changed in SwiftUI (related to UI tests) is the way accessibility IDs are added to a view.

Button(action: {}, label: { Text(“Submit”) })     .accessibility(identifier: “button_submit”)

#2 — Making a view accessible

Most of the challenges when writing UI tests comes with writing tests for lists and scrollviews. BitWall helped me understand the dynamics of it better. Most importantly, how an item in a listview can be made accessible, since usually an item view is a combination of controls where all of them can be accessible.

The biggest part of my learning here is to understand how to include or exclude elements for accessibility

VStack {     Text(“Build Number”)     Text(“10”)     .font(.title)}.accessibilityElement(children: .combine)


VStack {     Text(“Build number”)     Text(“10”)     .font(.title)}.accessibilityElement(children: .ignore).accessibility(label: Text(“Build number 10”))

The first example combines all textview into one, whereas the second example won’t even be visible to voiceover but will provide an alternative voiceover label.

This ended up being a really huge learning for me to understand how to access complex UI elements with SwiftUI in XCUI tests.

#3 — Understanding the lifecycle of the app

When an app is following a reactive architecture, understanding how everything comes together helps identify risky areas that we will need tests for.

For example, View Controller uses:


Whereas SwiftUI has the following:

Initialising the viewStates and bindingsonAppearonDisappear

#4 — removeTraits

In XCUI tests we tend to read elements based on traits, but here you will be able to use removeTraits to modify that behaviour, which is important to understand from a testing point of view.

.accessibility(removeTraits: .isImage)

#5 — Previews

SwiftUI has a really good preview mechanism. I found that one way to predict possible issues with the layout before testing is to have really good preview data, possibly a curated list of possible test data. This helps to envision the possible variations that the view can have. And with the preview allowing you to choose different device sizes, a lot of issues can be curbed during development.

ContentView()      .previewDevice(PreviewDevice(rawValue: “iPhone SE”))

#6 — Testing using the same framework as dev

I moved away from Appium a few years ago since it was a siloed way of looking at UI testing. It wasn’t able to keep up with the pace of improvements in XCUI tests or Espresso/UI automator. Therefore, the introduction of SwiftUI and its related changes also validated our decisions on how important it is to keep your tests as close to the dev framework as possible.


This is a very personalised experience for me. I am in no way saying that every tester should write his/her own app to be good at testing.

What I’ve tried to establish here is the way I see testing — a gray box rather than a black box. Understanding the native frameworks by learning to write an app has allowed me to come up with better ways to tackle UI testing.


BitWall, a type of wallboard as a concept and an idea was the brainchild of my mentor, Kelly Wason.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Transpire is a Melbourne-based mobile and UX consultancy trusted by Australia’s leading enterprises.