logigear/testarchitect repository overview

⁠Packaged components

The following TestArchitect components are packaged inside this image.

• TestArchitect controller – Tool that manages test automation. It is capable of handling automated testing of a local AUTs or an application running on other controller machines.
• TestArchitect command line - With this tool, tests can be launched from a command shell. When incorporated into batch files, the tool greatly extends the flexibility of test execution, especially from the standpoint of scheduling.
• Automation libraries, including:
  • API testing
  • Chrome testing

⁠Test environments

The TA Docker image has been tested in the following environments:

• Ubuntu 16.04
• Headless Chrome version 65 Any other environments not listed above are not actively tested by LogiGear. However, the TA image might run successfully on any Docker-supported environments. Note:
• The headless mode has been available on Linux since Chrome 59 (Learn more⁠).
• The headless browsers are web browsers without a graphical user interface. They are typically faster than real browsers; the reason being that since you aren’t starting up a browser GUI you are able to bypass all the time a real browser takes to load CSS, JavaScript and open and render HTML.

⁠Prerequisites

Remember: Please ensure that you have the latest version of License Server installed. For more information, please contact TestArchitect Support at [email protected]⁠. Note:

• It is recommended that you are familiar with the concept of Docker, especially installation and removal of Docker. You may refer to the topic below for details.
• Get Docker CE for Ubuntu https://docs.docker.com/install/linux/docker-ce/ubuntu/⁠.

⁠Running the TA image in Docker Container

Provided that you execute the commands below as the root user, you do not need to use the sudo command.

To run the TA image in Docker Container, carry out the following steps: #1. Open the terminal.

#2. Pull an image from LogiGear’s repository. $ docker pull <Image>:<Tag>

For example: $ docker pull logigear/testarchitect:8.3.4.5070

Where:

• logigear: Repository name
• testarchitect: Image name
• 8.3.4.5070: Tag of the image

#3. Start the TA image that you have just pulled. $ docker run -it --rm –p <publishedPort>:<TargetPort> --name <ContainerName> <Image>:<Tag>

For example: $ docker run -it --rm -p 53600:53600 --name TAInstance1 logigear/testarchitect:8.3.4.5070

Where:

• 53600:53600: Respective published port and target port; delimited by a colon. The published and target port ought to be identical. By default, Port 53600 is used.
• TAInstance1: A given name assigned to the container
• logigear: Repository name
• testarchitect: Image name
• 8.3.4.5070: Tag of the image

#4. Press the Ctrl + P + Q keyboard combination to detach from the from the Docker’s process; otherwise, the Listening on port: 53600 line keeps appearing which prevents progression.

#5. Run the automated test. In fact, there are three options:

Option #1: Running the automated test on the current container: $ docker exec -it <ContainerName> <TACommandLine> -c "localhost:53600"

For example: $ docker exec -it TAInstance1 <TACommandLine> -c "localhost:53600"

Where: is the "execute" command that triggers a TA test run

• You can type TA commands manually (Learn more⁠)
• Alternatively, you can quickly generate a batch file from TestArchitect, and utilize its content as TACommandLine (Learn more⁠)

Option #2: Executing an automated test remotely from another physical machine. a. On the physical machine with installed TA, invoke the Select Controller/Device dialog box. (Learn more⁠)

b. In the dialog box, enter the host address of the container, followed by its controller port number, separated by a colon.

c. Click the Execute button in the Execute Test dialog box to begin executing the remote test.

Option #3: Running an automated test from a batch file. This method helps you facilitate CI/CD pipeline implementation. a. As of the current releases of TestArchitect, generating batch files has only been supported on Windows and RedHat. Therefore, batch files (*.sh) must be generated on RedHat (version 7.2 recommended) and run on Ubuntu.

b. Edit the batch file as follows, before you run it. i. Insert #!/bin/bash as the first line of the file. ii. Change localhost to . For example: TAInstance1

c. Run the automated test using the batch file. $ docker run -it --rm -p 53600:53600 --name <ContainerName> -v </home/test/Desktop/Batch/>:</Batch/> <Image>:<Tag> <Batch_File>

Note that: The batch file is located in the host volume. It needs mounting to the docker container volume in order for the Docker container to use it.

Where: • -v </home/test/Desktop/Batch/>:</Batch/> : Mount the host directory that contains the batch file to a docker container directory • <Batch_File>: Path and name of the batch file on the Docker container.

For example: $ docker run -it --rm -p 53600:53600 --name -v /usr/local/local_test_data/Full_permission/Batch/:/Batch/ logigear/testarchitect:8.3.4.5070 "/Batch/Test docker.sh"

Where • /usr/local/local_test_data/Full_permission/Batch/: Host directory • /Batch/: Docker container’s directory • Test docker.sh: Name of the batch file on the Docker container

⁠Best practices

• It is highly recommended that you create a user-defined setting, named webdriver, as a startup setting (Learn more⁠).
• The JSON string should resemble the following. {"capabilities":{"browserName":"chrome"},"options":{"args":["--no-sandbox","--headless","--disable-gpu"]}}

This user-defined setting contains a JSON string value with following parameters:

• capabilities: Name of the capability and the type of value it takes.
  • browserName: The name of the browser being used.
• options: A list of all the Chrome-specific desired capabilities.
  • args: List of command-line arguments to use when starting Chrome.
    • --no-sandbox: Disables the sandbox for all process types that are normally sandboxed.
    • --headless: Run in headless mode, i.e., without a UI or display server dependencies.
    • --disable-gpu: Disables GPU hardware acceleration. If software renderer is not in place, then the GPU process won't launch.

In test procedures, we’ll obtain the JSON string value, defined in the webdriver user-defined setting, and then pass the value into the configure webdriver built-in action. The action lines might resemble the following.

configure webdriver [values: #getsetting("webdriver", "user defined, "")]
setting [setting: use browser] [value: Chrome]
navigate [location: https://www.google.com]
check window exists [window: [title={Googe.*}]]

In the above example, we open Google Chrome in the headless mode. Following this action, we have Chrome navigate to a given website. Finally, we verify the existence of the given website’s window.

Remember: Webdriver session is cleared, after each of test module’s run finishes. Therefore, it is highly recommended that test modules should be designed independently of each other. Specifically, each test module should contain the configure webdriver built-in action to initiate the headless Chrome.

⁠Using Java harness

When you’d like to program user-scripted actions⁠ in Java and adopt WebDriver, make sure the command * – export generic_webdriver=yes * – be present in the java_harness.sh bash file.

Note: By default, java_harness.sh is located at /usr/local/logigear/testarchitect/harness_samples/java/executables.

If the export command is not found in java_harness.sh, insert it as follows.

#!/bin/sh
#set path to TA bin directory
TA_BIN=/usr/local/logigear/testarchitect/binclient
JRE_HOME=/usr/local/logigear/testarchitect/jre
export LD_LIBRARY_PATH=${JRE_HOME}:${JRE_HOME}/lib/amd64/server:${TA_BIN}:$LD_LIBRARY_PATH
export generic_webdriver=yes

cd `dirname $0`
"${JRE_HOME}/bin/java" -jar java_harness.jar