Skip to main content
summaryrefslogtreecommitdiffstats
blob: fcd526ef213558e4ecafa0ffc6736e1449ea878f (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
\subsubsection{Actions}

\app{} supports ''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 \gdcases{} easier and quicker, and makes them more understandable. 

For example, \app{} offers two actions to enter text into a text field. The action \bxname{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 \bxname{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, \app{} 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 offered by \app{}. 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 \gdaut{}. 

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. 

\subsubsection{Test execution}
\app{} generally executes tests on your \gdaut{} by sending real clicks and key presses, in the same way that a manual tester would. This means that a \app{} 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. 

%In the cases where real clicks and key presses can't be sent, \app{} ensures that only actions which would be possible for a user can be completed in a test. 

Once clicks and key presses have been sent, \app{} waits for confirmation from the \gdaut{} that they have arrived (manual testers use their eyes, \app{} uses confirmers). 

If the \gdaut{} 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. 


\subsection{Standards conformance}
\app{} is designed to test components in their original
and intended implementations. If these components have been
derived and altered such that they no longer respond to actions in the
same way (i.e. rewriting the single-click event for a textbox,
non-standard responses to certain key combinations, etc.), \app{} may no longer be
able to test these components.

It is therefore recommended for the purposes of testing with \app{} --
and also for the sake of conformance to usability standards -- that
the toolkit conventions are held to.

There may, of course, be situations where exceptions are necessary. For this reason, \app{} has an API via which testing classes can be implemented so that even changed components can be tested. See the manual on extending \app{} for more information. 

Back to the top