Beginner in XCUITest don’t give up now!
Everyone is tired of reading that the test automation should be done in the same language as your team, your product. This has always been a great challenge for me as I have never had any contact with development.
Last year I immersed myself in the Robot Framework because I saw it as an opportunity to learn automation without learning to code. It is an incredible framework, and I always like to recommend it. The learning curve is minimal, the performance is excellent, and the possibility to automate all “fronts” (api, web, and mobile) in the same framework is excellent.
Until I got to where I am, the only QA in the company, we have had two big projects. These projects had over ten developers. This made it almost impossible to deal with as the lone QA. At that time, I thought, “I will learn to automate in their language so that they can help me with maintenance” This was a motto that Júlio de Lima always made it very clear.
I decided to start with iOS, took the QAZANDO course (in Portuguse) with Hebert Soares, and found it to be doable. So I’m going to show you a small step-by-step start-up and some tips that I discovered in the middle of my week.
Let’s go to “step by step”
1- Open your project in Xcode, menu “Editor” and “Add target.”
2- Choose the iOS UI Testing Bundle, click “Next”, choose the testing project’s name, and select the “Target” to be tested. Click on “Finish,” and your target is created.
3- When creating the Target, a class is created automatically importing the XCTest, creating a setUp and a tearDown and a test function, remembering that all test function must start with the word test so that Xcode understands that it is a test to be performed.
As in any test framework, setUp is where we can define everything that should happen before a test is started and the tearDown, which is the routine to be done after a test is finished.
To locate the elements on the screen, you can use the Accessibility Inspector from Xcode itself. The cool thing about being inside your app’s design is that if the element doesn’t have the necessary identifier, you can add it to your Dev code yourself.
In the case of swift, the best identifier is the Accessibility Identifier, and it is straightforward to declare there in the element:
TextField.accessibilityIdentifier = “hereIdentifier”
But a detail that nobody tells us (and thankfully, my development manager taught me) is that many elements we will only be able to find using the famous “po” or known as XCode’s debugging tool.
Putting a breakpoint in your code and using lines like:
po XCUIApplication().debugDescriptionpo
XCUIApplication().buttons
you can use the app instead of XCUIApplication () if you declare in your project: “let app = XCUIApplication ()”
And here is a cool article I found through the Test Automation University course that teaches different ways to find elements
https://www.hackingwithswift.com/articles/148/xcode-ui-testing-cheat-sheet
The organization of your tests is up to you and your team. I chose to keep a “Page Objects,” in a group are all the Pages with the codes themselves, in the group Test the test files are to be separated in the same way the other files of the tests are to be executed. I have a helper with a file that has all the “key” functions to facilitate.
You also use the famous BDD / Guerkin yes in XCUITest was not my decision. Here is a good article if you want to read about it:
https://bitbar.com/blog/bdd-for-xcuitest-with-swift-protocols-and-extensions/
Speaking of BDD and Gherkin has this post fromWagner Silva Torres it is TSPI Magazine that explains what it is and how it should be used.
Okay, but come on, how to create a click? or fill in a field?
After everything is prepared, the project is already running, and you have the Accessibility Identifier of what you want to validate on the screen. How to recreate the user action?
A click on any element on the screen in the swift is tap () and writing in a text field is through typeText; we can see an example:
In the short and straightforward example above, we can see that first defined, which is the element that will be interacted, we give it a “name” and pass on its identifier. Then the click action to focus on the component and then we pass the text we want to fill with typeText and lastly a nice little secret that can be very useful is also to send the \ n which and the action that “skips” to the next one element on the screen (in the form of a form can be handy to avoid having to keep giving .tap () every time).
With that, we have a basis on how to start testing your Native iOS project, now part of you exploring this universe and getting deeper. The hardest thing is getting started :)
It is not a subject that there is much on the internet, so I recommend the QAZando course again with Hebert Soares, the free course from Test Automation University, and some YouTube channels I found along the way; I also recommend a free course on Swift that my iOS dev from Hanzo sent me, it’s fascinating.
I hope to have brought some friendly content to be read and useful for the QA community :) Let’s go to the CODE!!
100 days of Swift — Free Course
TAU — Introduction to iOS Test Automation with XCUITest
Youtube Channel — Eugene Berezin
Youtube Channel — QA Underground
Blog Leonardo Pugliese — Dev iOS
