Automated UI Testing In Swift & Amp For iOS Devices


UI testing: An overview

How do we get started with this? What is ui testing? Testing is a very difficult process. We can talk about both manual testing and automation testing. Now the latter will be the topic.

For iOS applications, we distinguish between two types of testing

Unit test 

UI test

During a unit test, we test the functionality of a class or its method, while during a UI test, it is no longer broken down into units, but the interface of the application is important. We can log in to the application, we can register but it is also possible to test a smaller item, such as whether we can click on a cell. But what do we need to get started?

What is automated UI testing?

Is automated UI testing worth it?

How do you automate Web UI testing?

What type of tests are suitable for automated testing?

Create a test scheme

Create a new project and check the “Include UI Tests” option in the project settings.

Creating a new project
Project created

After this appeared in the Targets among the UITests, however, we do not find it among the schemas. So, it should be added. This will be used to run the tests. To do this, select the current scheme and select the “New Scheme” option. Then enter the schema name in the new window and select the UITests target.

Add a target
Target added

The application and the test case are then installed on the device. Then, it runs, naturally successfully since there is nothing currently in the method.

There are two methods in this class. The setUp and teardown. Both play an important role in running the tests. 

The setUp method runs before each test method, i.e. in this method, you have to place the settings that you want to run before tests. TearDown will run after each test method.

Accessibility Identifier

To access any component in our test cases, we need to add an ID to it. This can be specified with the accessibilityIdentifier attribute. In theViewController.swift file, create a method called addAccesibilityIdentifiers .

Enter a unique ID for each label and button, and call the method in viewDidLoad . 

Go back to our test file and create the reference for your test application and launch it as well.

We need to find the ID based on the button that the test will click on. To do this, we need to create an XCUIElementQuery . We want to interact with any component, we can always achieve it with such a query. The component can be: 

– staticText (label) 

– button 

– textField 

– secureTextField 

– textView 

– searchField 

– slider 

– otherElement (View)

To access the button we need to enter the interface

Important: The ID must match the ID entered above, and you must search for this ID between the keys.

This will be the query itself and you can click on it:

Click the sign next to the method again and run the test. Success!

Now we expand on that. After the click, we have to check whether the top text has disappeared and whether the middle text has changed. To do this, supplement our test method with the following.

The exists attribute specifies whether the component is present on the screen, and the XCTAssertFalse method is successful if the value of the parameter in it is false. It is paired with the XCTAssertTrue method which is successful if the value of the parameter in it is true. Let’s run the test and see that our test is still successful.

Examine the middle text for “Bye”. To do this, expand the method further with the following.

The XCTAssertEqual method compares two values ​​and is successful if the values ​​match. An attribute of a query label specifies the text of that query. This way you can make sure that the text shows “Bye” after pressing the button.

Manage IDs:

In the previous code, the IDs were given as strings, but sooner or later this may cause problems. Accidentally misspelled characters and then half an hour or hour of debugging to find out what could be the problem. It is therefore important to centralize the identifiers. Create a file from within the application AccesibilityIds under which they are revealed.

With this enum, we will reference the IDs to avoid typing. However, it is important to access this file in both targets. To do this, select the file and check both targets on the right.

Then replace the IDs within the methods with the following, first in the test file:

Then in the app itself:

Run the test again. Success!

Basis for ui testing!

In this small demo application, we have easily achieved that after clicking a button, we check whether all components are found or whether their value has changed or not. The final status of the demo application is available here. Of course, this is just the basis for testing the UI, as an application usually has a much more complex interface and has more functionality.

Now you must know about UI Testing, ui testing test cases, automate ui testing and the ui testing framework.