4.8.6. Working with iOS components and actions

When testing iOS AUTs, many of the components will be similar to those found in desktop AUTs. You can use the actions from the unbound_modules_concrete library to perform actions such as:

The following sections deal with how to use actions to address specific components in iOS.

4.8.6.1. Working with iOS switches

Switches in iOS AUTs (Figure 4.1, “Switch”) can be addressed using the actions:

  • Click (to tap the switch). Depending on the AUT, this will toggle the state of the switch.

  • Other actions on the Graphics Component such as check existence, wait for component etc.

  • Swipe. By entering a direction, you can specify whether to activate or deactivate the switch.

  • Check selection (Button Component) - use this to check whether the switch is activated or not.

Figure 4.1. Switch

4.8.6.2. Working with iOS Table Views (lists)

  • Table Views in iOS are used to organize information on the screen. They may just consist of items (and therefore look like a simple list (Figure 4.2, “Simple Table View (list component)”)), or they may contain various sections – each section can contain other components (Figure 4.3, “Grouped Table View (list component)”).

  • Both types of Table View are testable using the actions available on the List component.

  • You can, e.g. select items from the list, check their existence etc.

  • In the Table Views that contain other components, you can also address the individual components (labels, buttons etc.) in the list using the actions such as check existence, check text, click etc.

  • When writing a test on these components, it is important to decide which component you want to test (Section 4.8.5, “Addressing the correct component in your iOS tests”).

  • If you need to scroll to a certain section of a list that is currently not visible, you can use the select action on the list component to make the correct portion of the screen visible. You can also use 0 clicks to simply hover over the item instead of tapping it.

    Bear in mind that many apps remember where you were on a screen. You may need to add explicit scrolling (via selection) to your tests in order to ensure that the components you require are on screen.

Figure 4.2. Simple Table View (list component)

Figure 4.3. Grouped Table View (list component)

4.8.6.3. Working with iOS tabbed controls

  • Many components in iOS AUTs can be addressed as tabbed controls – in a similar way to tabbed panes in a Swing AUT for example.

  • The components tabbed bar and segmented control (Figure 4.4, “Segmented controls (tabbed controls)”) are examples of two components that can be addressed with the actions on the tabbed control component. You can select a tab based on its content or its index, check the selection of a specific tab, check the existence etc.

  • In many cases, you will also be able to map the individual tabs as e.g. buttons or labels. As described earlier (Section 4.8.5, “Addressing the correct component in your iOS tests”), we highly recommend ensuring that you are addressing the most relevant and high-level control for your test.

Figure 4.4. Segmented controls (tabbed controls)

4.8.6.4. Working with iOS pickers

  • The iOS components pickers can be addressed using actions for combo components.

  • You can select items from pickers that have only one column (Figure 4.5, “Single picker (combo component)”) using the actions for combo component in the concrete toolkit. You can also check the existence of items in the picker, check their selection etc.

  • To work with pickers that have multiple columns, you should use the actions in the iOS toolkit to select from the picker based on the column value. In this way, you can specify which column the selection should take place in.

Figure 4.5. Single picker (combo component)

Figure 4.6. Picker with multiple columns

Hints for working with pickers

Check text on multi-column pickers:

If you use the action check text on pickers with multiple columns, the result will be a concatenated value of all columns.

Grey items not addressable:

Items that are grey in the picker cannot be checked or selected.

Index-based selection on infinite pickers:

Some pickers do not have a finite amount of items – they scroll infinitely. We strongly advise against usin index-based selection or checking on such pickers.

4.8.6.5. Working with gestures

  • In the iOS toolkit, you will find swipe actions for many components. You can use these actions to perform swipes in a specific direction.

4.8.6.6. Working with the keyboard

  • To use actions such as replace text, you do not need to worry about using the keyboard – the test execution component does this for you.

  • However, if you would like to press specific buttons on the keyboard such as »DONE«, »DELETE« and so on, then you should use the action in the unbound_modules_ios called Tap View with Accessibility Label.

  • This allows you to press any item on the screen (on the keyboard or elsewhere) based on its accessibility label:

    • The accessibility label is an internal attribute for a component that is designed to be used by screen readers etc.

    • You can find out the accessibility label for an item by using the Accessibility Inspector on e.g. an iOS simulator. You can activate the Inspector via the General Settings.

    • Once you know the label, you can enter it as a parameter (exactly as it is written).

    • Bear in mind that accessibility labels are language-dependent (i.e. you will need to translate the test data), and also sometimes orientation-dependent. It is also not necessarily the case that the accessibility label is the same as the text on the item that is visible in the AUT.

Many iOS devices have a setting activated to start each text with a capital letter. We recommend deactivating this setting for your tests, as attempts to enter lowercase text at the beginning of a textfield will otherwise fail.

4.8.6.7. Working with unmappable (unsupported) components

If there is a component that is unsupported, then you may be able to tap it using the action in the unbound_modules_ios called Tap View with Accessibility Label. For more information on this action, see the section on working with the keyboard (Section 4.8.6.6, “Working with the keyboard”).

4.8.6.8. Other important information for testing iOS AUTs

Non-supported components
The following components are not a part of the iOS toolkit, and their actions from the concrete toolkit cannot be used in iOS tests:

  • Menus

  • Tables

  • Trees

  • Context menus

Non-supported actions
The following actions are currently not supported:

Restart:

The restart action restarts the internal connection to the AUT, not the AUT itself. This means that you should consider how to reset your AUT to a known starting point as part of your Event Handlers (to ensure that the test can continue despite an error). How to do this will be dependent on your AUT.

Check text on secure textfields:

The text on a secure textfield cannot be accessed, e.g. to perform check text.

Check / store property

actions are not supported in the current version.

Copy to clipboard

is currently not supported.

Other information

No detailed information on test failure:

When a Test Step fails, there is currently no detailed information about the reason for the error.

Support characters for text input:

Any keys on the keyboard that are only accessible by a long press, and not by switching the whole keyboard (e.g. characters with umlauts) cannot currently be entered.

Long taps and continuous gestures:

cannot currently be carried out.

Disabled components

cannot be mapped directly using e.g. tap. Instead, to collect the technical name for a disabled component, you should use the long tap gesture to collect all of the visible components. This includes the disabled components.

Check badge value

There is an action in the iOS unbound modules to let you check the text on badges within a tab bar.



Copyright BREDEX GmbH 2015. Made available under the Eclipse Public License v1.0.