Tips & Tricks gleaned for Writing functional iOS UI Tests

Previous Tips:

Part 1

Part 2

Part 3

LaunchArguments

Here I come again with some new tips when writing iOS UI tests which will enrich the tests and make them easy to understand or change.

When we talk about tests maintainability, of course we would talk about following some design patterns for tests which I mentioned in a previous blog post. However in this blog post I will be talking about different area of keeping tests readable, maintainable, structured and easy to understand.

So in order to achieve that we need to make our tests Functional.

Maybe the things I got lucky at when I was starting to learn about test automation is that I learned the BDD approach of Given, When, Then which helped me structure my thoughts and steps when writing any new test case for automation even when I am still brainstorming my ideas on paper with no code involved.

So how we make our tests Functional?

I follow the below steps

1. Setup and Prepare
2. Do User Interactions
3. Add One Functional Assert

If I think it in a BDD Way, the same flow would apply

1. Setup and Prepare (Given)
2. Do User Interactions (When)
3. Add One Functional Assert (Then)

But also I would talk on another perfect pattern we need to follow when we structure our tests which is Arrange Act Assert

It is originally should be used when writing the unit tests but let’s imagine this, we are writing some UI tests which is a user tests or a user-ui-flow tests so we need to be functional so the pattern would for sure suites the UI tests as well.

To simply describe this awesome pattern:

1. Arrange: arrange our setup code for the test to run successfully, like initial steps, mocks, initial app state, or any test data.
2. Act: This is where our user interactions come, which if we follow the POM, these are the time of providing the user interactions/ steps we added on each page/screen of the app.
3. Assert: Time to verify our output of the test, to check if it is passing or failing. But we should make sure to add one functional assert per test meaning that test only tests one output. This output maybe has multiple of values to assert but at the end they test only one output.

Arrange Act Assert in action:

Now it is time to get our hands dirty and write some code ;)

If we have a feature of “Adding a Note to Notes App”

If we would follow BDD, it would be structured as follows:

1. Given Notes app is opened (also all mocks are ready if any)
2. When I add note (involves tap the button and write note then save it)
3. Then Note should be displayed in saved notes

Let’s put that into code with Arrange Act Assert pattern:

Arrange

We launch the app with extra arguments and add our required mocks

Act

We already have our page object with user actions required to add a note

Assert

Time for the verification of the test output

All in All

Then we have our complete readable test

If we think about stakeholders reading our automated tests in this clean and structured way:

• New Test Automation Engineer joined
• Developer interested in writing UI tests
• Product owner
• Manual Tester interested in Test Automation
• Any colleague from the company

All of them would easily follow the tests we wrote and understand what feature this test is about.

HAPPY TESTING!