Excepciones a las prohibiciones para las especies incluidas en el Listado

The target-side of TestGFX is responsible for receiving, interpreting and executing test commands from the host on the target AUT. In order to support high maintainability and extensibility princi- ples of component-based development are used.

The target design shown in Figure 4.5 is governed by a generic core component which defines the procedural logic of the target TestGFX framework. The core serves as the main point of entry to TestGFX on the target.

The following sections contain detailed descriptions of the components of the target design. Cur- sory readers may skip to Section 4.4.4 which presents the dynamics of the target design in relation to TouchGFX.

4.4.2.1 Core

The primary class in the Core component is the TestAgent. The TestAgent provides a single method, “testProcedure”, for repeated execution in an appropriate context. This method is de- signed to be invoked in the main event cycle of a GUI framework. An event cycle is defined as an iteration of input sampling and processing in the GUI framework. The event cycle of TouchGFX is described in Section 4.4.3. With each event cycle, the TestAgent will listen for and interpret command messages from the host and add them to an internal FIFO queue for later execution. Once per event cycle a single command will be taken from the queue and executed by the TestA- gent. The dynamics of this behavior is presented in further detail in Section 4.4.4. In order to receive commands from the host the TestAgent utilizes a ProtocolClient.

The ProtocolClient utilizes a Transport instance for low-level communication with the host and a ProtocolInterpreter instance for interpretation of binary messages into Command objects. The

Command

Figure 4.5: Design of TestGFX on the target.

specific Transport instance used is instantiated by the context of the TestAgent as it is platform- specific. The ProtocolClient populates the internal list of commands in the TestAgent, which are continuously executed with each invocation of the “testProcedure”. This process is described in detail in Section 4.4.4.

The TestAgent uses a StateClient in order to retrieve the state of the AUT. The StateClient pop- ulates an internal byte array in the TestAgent with state information from the target. The imple- mentation of the state acquisition is defined by the State component, described in Section 4.4.2.4. The TestAgent also relies on an Application Abstraction Layer (AAL) interface in order to reset the AUT. The implementation of the AAL is application-specific and defines a contract between the AUT and the TestAgent. For a TouchGFX application to be TestGFX-enabled it must implement a concrete instance of the AAL, which defines a “Reset”-method for the application. Resetting the AUT is a very important feature for a test automation framework. The AAL interface is described further in Section 4.4.3.4.

4.4.2.2 Command

The command component consists of implementations of the abstract Command class provided by the TestGFX core. A concrete Command constitutes an instruction parsed from a protocol packet received from the host. Commands are used to perform test related actions on the target. The Command implementations are divided into two conceptual categories: event commands and control commands. Event commands, e.g., click and drag, represent GUI events to be activated

Chapter 4. Test Automation on Low-Resource Embedded Systems

on the AUT and control commands, e.g., state and reset, represent high-level test-related actions to be carried out by the TestAgent.

The command abstraction used here is based on the Command Pattern [17]. Every command contains information about its own invocation and is managed based on its Type attribute. The command type refers to the conceptual category mentioned earlier. By discerning the type of the command the TestAgent is able to determine how to execute it. In the case of an event type com- mand a touch event is sent to the application, while a state- or reset type command will prompt the TestAgent to acquire and return the state of the GUI or reset the AUT through the AAL respec- tively. These processes are described in detail in Section 4.4.4.

4.4.2.3 Protocol

The protocol component consists of implementations of the abstract ProtocolInterpreter class. These interpreters implement the parsing of packets from the host, described in Section 4.4.5.1. The concrete ProtocolInterpreters are directly related to the concrete Command implementations, with the exception of control commands as each command is created by a dedicated interpreter. The protocol component implementation is based on the Interpreter Pattern [17]. This enables easy extension of parsing capabilities as the addition of a new packet type from the host only requires the implementation of a new ProtocolInterpreter and possibly a new Command.

4.4.2.4 State

The state component consists of GUI framework-specific implementations of the abstract State- Client. For the TouchGFX GUI framework a TouchGFXStateClient is provided. The extraction and processing of the GUI state on the target depends on the design of the GUI framework. The implementation of the TouchGFXStateClient, shown in Figure 4.5, is based on the Interpreter Pat- tern[17] and is designed to enable interpretation of the hierarchy of Drawable implementations found in TouchGFX core described in Section 4.4.3.

4.4.2.5 Transport

The transport component consists of implementations of the abstract Transport class. The Trans- port implementations are related to available hardware components and drivers for external com- munication on the target platform. The UART implementation, illustrated by Figure 4.5, imple- ments serial communication via an RS232 interface. The abstraction of low-level communication mechanisms from the core increases transferability by enabling easy extension for heterogeneous targets.