All Case Studies Design Development Interviews Our Way Project Management

Make Your UI/Functional Testing Easier with XCTest

When it comes to mobile testing (well, testing in general) every QA specialist in the world does way too many manual tests. It's very time-consuming and often frustrating. So why would one do that? How can one avoid it? At Netguru we have been testing for over 8 years. We have some experience in mobile testing, and I would like to share with you some tips on how to automate your iOS testing, at least part of it.

Let's meet XCTest. XCTest is a testing framework that enables the user to automate UI/functional testing. Its syntax is easy, and if you are familiar with any other testing framework like Capybara, you’ll grasp it in no time. Therefore, we decided to use it and share it with you.

How to Create a Testing Script for iOS


  1. Download the newest Xcode.

The newest is not actually a must, but XCT was a feature introduced in Xcode 7.


  1. Watching this video is a MUST. 

This is a great video of UI testing in action from WWDC 15, where the presenters talk about the possibilities and syntax of XCT. The cases presented in the clip are basic, but it should be more than enough to get started with. Note that you can only watch this video in Safari.


  1. Write down all the use cases you can think of.

Call me old-fashioned, but I prefer doing such chores by hand. These should be simple:

  • as a user, I want to register,
  • as a user, I want to log in with valid credentials,
  • as a user, I want to reset my password.

Nothing too fancy, just raw scenarios to give you something to start from.

00002405.png


  1. Draw views in a UX manner.

Having wireframes for views in the app will let you quickly imagine the scenarios that can be performed in each view. For instance, I have drawn a simple registration view consisting of 3 fields and 1 button (email, password, password confirmation and a send button). You can see it on the picture below.

Looking at these, I know that fields must be validated. Mail addresses cannot be duplicated and password fields should be validated if the user’s password is, say, 8-character long. This allows me to see the bigger picture.

00002404.png


  1. Think of validations.

These will exhaust use cases associated with fields and forms within the app as some people will try violating the existing rules. Did I say some? I mean the bunch of kids that are going to use your app.


  1. Take a break. Have a coffee.

Remember to take short breaks because no one can stay focused for more than 30-60 minutes.


  1. Take a glimpse at #3 and see which tasks are most mundane and repetitive for you.

This is important because people make mistakes, and so do QAs, testers, developers and presidents. Performing a task that is repetitive might result in making mistakes and worse testing performance. If I had to register dozens of new accounts for each new version, I would probably end up in a specialised hospital wing faster than I could spell m-u-n-d-a-n-e.

km6xn.jpg

Moreover, I would probably find my attention slipping after the first few times... There is a remedy! Take a chill pill, sit tight and identify which chores are boring for you. Write them down and repeat steps 3-6.


  1. Once you’ve got the use cases, go ahead and write down test cases.

This is pretty self-explanatory as writing test cases is like writing tests but in the natural language. For example:

  • User types the valid email.
  • User types the valid password.
  • User types match confirmation password.
  • User clicks send.

00002403.png


  1. Transform your test-cases into XCT scenarios.

Having all of the above makes it fairly simple to write tests at a faster pace. An exemplary test case for a successful login:

20.pngThis is not perfect. Hence point 10.


  1. Debug, refactor and nurture.

Things can be always made better and optimising your tests is no exception. The test above can be easily improved. All the `lets` I have within the function are not in the best place. What if I wanted to make another test using the same fields and buttons? If button labels changed, I would have to rewrite them in each test I wrote, which would be pointless.

After a quick refactor, I made this test more efficient.

2-2.png

Obviously, this solution is not the best - being aware of this is crucial because it is what makes me want to improve it.

To sum up, automating with XCT is not so easy at the beginning, but it is achievable in a reasonable period of time; I believe that these are the solutions that make testers’ lives a little bit easier - saving some precious time which could otherwise be spent watching cats or drinking coffee. I hope that you find my tips useful. Don’t hesitate to comment on my post and if you have any tips yourself, feel free to share them.

Scanning SaaS for CEOs
 
READ ALSO FROM QA
Read also
Need a successful project?
Estimate project or contact us