Besides the implementation of the MVP pattern, the TouchGFX core provides several visual com- ponents, or drawables, and touch event definitions, presented in Sections 2.4.2.3 and 2.4.2.4 re- spectively. Furthermore, the core provides means for the definition of transitions and application management, described in Sections 2.4.2.2 and 2.4.2.5 respectively.
2.4.2.1 Views and presenters
An application screen is implemented in two parts: a view and a presenter. While the presenter handles GUI events and information mitigation from the model to the view, the composition of the view is of primary focus when developing a GUI testing framework. Figure 2.10 gives an example of a TouchGFX application screen in a simulated environment.
Figure 2.10: TouchGFX example application in a simulated environment.
A view is composed of a number of visual components. It has an internal root container to which each component is added sequentially. This process forms a linked list of GUI objects, illustrated
Transitions
by Figure 2.11, and the result is a hierarchical object-oriented structure representing the current screen or state of the GUI.
The root container is utilized by our GUI testing framework in order to extract the state of the view. This process is described in Section 4.4.
Figure 2.11: View composition of the TouchGFX example application.
2.4.2.2 Transitions
Changes between view and presenter pairs on run-time are referred to as transitions. A transition defines how the application switches from one view context to another. This entails deallocation of the current view and presenter and allocation of the new.
Transitions are implemented by transition-event handlers in the application layer, and in our GUI testing framework they are used in order to reset the application to an initial state, which is a crucial feature in a test automation framework. This process is also described in Section 4.4.
2.4.2.3 Visual components
Visual components are GUI objects which can be added to a view definition to constitute an application screen. They are provided by the TouchGFX core as a series of drawables specialized into containers and widgets.
• A container describes a visual component, which may contain widgets and other contain- ers. In a tree hierarchy, a container may be considered a branch node. Notable container implementations provided by TouchGFX include the Container base class, the Scrollable Container and the List Layout.
• A widget describes a visual component with a specialized purpose, that can not contain child elements. In a tree hierarchy, a widget represents a leaf node. Notable widget imple- mentations provided by TouchGFX include a Button, a TextArea and an Image.
As described in Section 2.4.2.1 adding widgets and containers to a view creates a hierarchical two-dimensional linked list. Widgets and containers are specializations of the same abstract class, Drawable, and contain basic information related to GUI objects, such as position, size or visibility.
Chapter 2. GUI Testing of Embedded Systems
In addition to this, each derived Widget and Container contains specific content related to its function in the GUI. While the content of a container is a list of child drawables, every widget may have its own type of content relevant to its use, e.g., a TextArea containing textual content. The ability of a GUI testing framework to determine the type of and extract content from drawables is a prerequisite in order to acquire the state of the GUI.
2.4.2.4 Touch events
A touch event is defined as an application level abstraction of a user intent produced by physical stimuli to a touch-enabled display. Identifying such events is an important aspect of the TouchGFX framework as each event type maps to a specific event handler. In general TouchGFX supports three types of touch events: clicks, drags and gestures. While the first two are well-known from traditional desktop application interaction, the latter encompasses generic inputs enabling the im- plementation of more sophisticated interaction such as the flick gesture known from smartphones and tablets.
Each event type is defined by a series of properties relevant to the user action it represents. A click event is defined by its direction, i.e., held down or released, and the coordinates of the interaction on the physical interface. This means that user interaction in TouchGFX is coordinate-based, leaving it to the test framework to provide the proper GUI object abstraction if it is to alleviate the maintainability issues of coordinate-based GUI testing, described in Section 2.2.3. In our GUI testing framework this abstraction is provided via heuristics-based GUI object recognition, described in Section 3.4.4.3.
2.4.2.5 Application front-end
The front-end of a TouchGFX application is responsible for the management of GUI resources, the navigation between screens and interfacing to other components including the HAL and the application itself. It consists of concrete implementations of the abstract Heap and Application classes.
• The heap handles resource allocation for the entire application. This is done by identify- ing the largest view, presenter and transition and allocating the memory sufficient to con- tain these at the same time. A concrete heap, such as the FrontendHeap shown in Fig- ure 2.8, contains an optional Model along with the concrete application instance. As such, the heap provides a single application object, which manages all of the memory allocated for a TouchGFX application.
• The application base class defines means for lower-level components, e.g., the HAL, to for- ward identified touch events into the application execution. This makes it possible, through the application instance, to invoke specific touch events on the GUI enabling a test com- ponent running in the same context to control application execution. Concrete application implementations, such as the FrontendApplication shown in Figure 2.8, defines available transition-handlers to switch between application screens.