6.3.2. Understanding how the ITE and test execution work
Prev | 6.3. Testing | Next

### 6.3.2. Understanding how the ITE and test execution work

#### 6.3.2.1. Actions

For test execution, we support ”high-level” actions. By this we mean that some of the actions which can be chosen for a component actually carry out a number of actions. This makes the creation of Test Cases easier and quicker, and makes them more understandable.

For example, there are two actions to enter text into a text field. The action Replace Text selects the whole text in the component and then enters the text input. This effectively overwrites any text which was already in the component. The Input Text action clicks once in the component and then enters the text, which means that any text previously in the component remains.

Another example is the selection and navigation through trees and menus. Like a human tester, the test execution works using the path to the item to select, and doesn’t first have to select the individual sub-items in the path.

High-level actions can be used on all standard components without problems. However, if the behaviour or look-and-feel or a component has been changed (e.g. double-click in a text field brings up a dialog instead of selecting the word) then some high-level actions may not work. In this case you will have to combine the low-level actions. Often, there are many ways of achieving the same effect in your test, and it may just be a case of trying out a few different ones to see which works for you and your AUT.

When writing tests, it helps to be aware of things that a human tester does implicitly. Often, these are things that have to be explicitly stated in an automated test, like waiting for the application to be ready, or selecting an item before opening the context menu, or even pressing enter to close a cell editor in a table.

#### 6.3.2.2. Test execution

Tests are generally execute by sending real clicks and key presses, in the same way that a manual tester would. This means that a test will give you the same results as a manual test – if a menu is disabled, an item can’t be selected and so on.

Once clicks and key presses have been sent, we wait for confirmation from the AUT that they have arrived (manual testers use their eyes, we use confirmers).

If the AUT or the components in it need to be scrolled to access the area being tested, scrolling happens automatically. In the same way, if a tree is collapsed, you do not need to specify an expand action before selecting a node. The expansion is done as part of the selection.