Configuration

Contents

Overview

At startup, the OpenTest server looks into its working directory for a configuration file named server.yaml. This working directory is also the location where all the dynamically-generated data will be stored (database, log data, screenshot files, etc.).

Similarly, the test actor looks into its working directory for a configuration file named actor.yaml and saves all the data it generates into that same directory.

You can create multiple working directories for the OpenTest server and for the test actor(s) and switch between them as necessary to prepare for executing various test automation scenarios.

Server configuration

Location

The server configuration file must be located in the root of the server’s working directory and is named server.yaml. You’ll typically want to create a directory structure similar to the one shown below, containing the server’s working directory, the test actor’s working directory and the test repository directory:

C:\opentest
├── server
│   └── server.yaml
├── actor1
│   └── actor.yaml
└── test-repo
    └── ...

Here’s a typical server.yaml file:

C:\opentest\server\server.yaml
# The port the server listens on
serverPort: 3000

# The path to the root of the test repository directory
testRepoDir: C:/opentest/test-repo

Best practices

When working simultaneously on multiple test automation projects, a best practice is to have multiple server working directories, and have each one of them point to the project-specific test repo in its server.yaml file. For example:

C:\opentest
├── server-proj1
│   └── server.yaml
├── server-proj2
│   └── server.yaml
└── test-repo-proj1
│   └── ...
└── test-repo-proj2
    └── ...

The server.yaml file for the first project would look something like that:

C:\opentest\server-proj1\server.yaml
testRepoDir: "C:/opentest/test-repo-proj1"

When you intend to start working on a particular project, start the OpenTest server in the directory that corresponds to the project you want to work on, by specifying the working directory at the command line:

opentest server C:\opentest\server-proj1

Parameter list

The configuration parameters in the table below can be used in server.yaml files to control the behavior of the OpenTest server.

ParameterDescription

acquireActorsTimeoutSec

Number of seconds a test session will wait to acquire the necessary test actors before it is cancelled. Default: 1200.

noActivityTimeoutSec

Number of seconds a test session will be cancelled after, when there is no activity (no actors are making any progress executing test segments). Default: 3600.

serverPort

The port the OpenTest server listens on.

testRepoDir

The path to the root of the test repository directory.

actorGroups

Actor groups can be used to limit the number of actors that can run in parallel at any given time. In the example below, the OpenTest server will ensure that actors tagged with bs will never run more than 5 parallel test sessions.

actorGroups:
  - name: BrowserStack
    actorTags: bs
    maxParallelSessions: 5

  - name: Compute-Intensive
    actorTags: compute
    maxParallelSessions: 2

adminLogin

The user name required for HTTP basic authentication. If set, the OpenTest web UI and API will require authentication. If you use authentication, please make sure to specify the credentials in the actor.yaml files of` your test actors.

adminPassword

The password required for HTTP basic authentication.

urlPrefix

The prefix to be used for all the URL paths. For example, if the prefix is set to opentest, all URLs will be of the format http://domain:port/opentest/. This comes in handy when running OpenTest on a server that might be hosting multiple other services or when running multiple OpenTest instances on the same server/domain.

Test actor configuration

Common parameters

The parameters from the snippet below must be present in every actor.yaml file. The most important (and mandatory) parameters are actorType and syncServerUrl.

C:\opentest\actor-web\actor.yaml
# A string that specifies the type of actor that will be created. This
# can be any string - as long as the same string is going to be used in
# the test definition files - but it's recommended to use an uppercase
# three-leter string (e.g. WEB, MOB, API, etc.)
actorType: WEB

# Actor tags can be used to determine what test actor will execute a particular
# test session when mutiple actors of the required type are available.
actorTags: [ chrome ]

# Possible values are: TRACE, DEBUG, INFO, WARN and ERROR
logLevel: TRACE

# The URL to the OpenTest server
syncServerUrl: http://localhost:3000

# This password will be used when the test actor encrypts or decrypts data as
# part of the $encrypt and $decrypt JavaScript APIs
encryptionPassword: skdhglaK

# Determines whether decrypted secrets will be masked in log files
maskSecrets: false

Please note that the Selenium-related parameters are all placed under the selenium property.

C:\opentest\actor-web\actor.yaml
#...

selenium:
    # The URL of the Selenium server. If this parameter is not specified, a
    # local Selenium driver will be instantiated, as specified in the desired
    # capabilities section
    seleniumServerUrl: http://127.0.0.1:9515
    desiredCapabilities:
        browserName: chrome
        chromeOptions:
            args: [ --start-maximized ]
    chromeDriverExePath: C:/Selenium/chromedriver.exe
    chromeDriverExeArgs: [--start-maximized, --ignore-certificate-errors]
    edgeDriverExePath:
    firefoxDriverExePath: C:/Selenium/geckodriver.exe
    ieDriverExePath:
    operaDriverExePath: C:/Selenium/operadriver.exe
    safariDriverExePath:
    systemProperties:
        # property1: value1
    maximizeWindow: true
    scriptTimeout: 20
    # Determines how long to wait for a web element to appear in the page
    # before failing the test
    explicitWaitSec: 10
    # Instructs the test actor to reuse the same browser window every time a
    # test is run. This can be very beneficial during test development, but is
    # likely not wise to keep enabled in production.
    reuseDriver: false

Please note that the Appium-related parameters are all placed under the appium property.

C:\opentest\actor-web\actor.yaml
#...

appium:
    appiumServerUrl: http://127.0.0.1:4723/wd/hub
    # For more information see the Appium project's documentation at
    # http://appium.io/docs/en/writing-running-appium/caps/
    desiredCapabilities:
        app: /Users/username/application.app
        automationName: XCUITest
        deviceName: iPhone Simulator
        platformName: iOS
    # The amount of time the test actor should wait when searching for UI
    # elements before throwing an exception
    explicitWaitSec: 10
    # Instructs the test actor to reuse the same app instance every time a
    # test is run. This can be very beneficial during test development, but is
    # likely not wise to keep enabled in production.
    reuseDriver: false

API testing parameters

Please note that the API testing parameters are all placed under the api property.

C:\opentest\actor-web\actor.yaml
#...

api:
    # Allows the HTTP client to ignore the web server certificate. Useful for
    # working with servers that are using self-signed certificates.
    ignoreCert: false
    # The HTTP proxy server to use when doing API testing using the the HttpRequest
    # action. This is useful when behind a firewall, or for capturing the outbound
    # HTTP requests with tools like Fiddler or Charles.
    httpProxy: localhost:8888

Best practices

When working with multiple test actors (e.g. WEB, MOB, API), you should create multiple test actor working directories, each one of them containing the actor.yaml file for a particular test actor. You should also put the test actor type in the name of the directory for easy identification. For example::

C:\opentest
├── actor-web
│   └── actor.yaml
├── actor-mob
│   └── actor.yaml
└── actor-api
   └── actor.yaml

You can then start each test actor by specifying its working directory at the command line:

opentest actor C:\opentest\actor-web