Skip to content
/ .. /
Introduction





Configuration

This chapter contains information about configuration files used by intaQt and other QiTASC products, such as the intaQt Phone Service and the HTTP Server. For configurations regarding intaQt languages (UI Steps and Steps), Built-ins and Verification, refer to their respective sections.

intaQt recognizes all files that end with the .conf extension as configuration files. These files can be created and managed using text editing applications such as Sublime Text, or from within intaQt Studio. By default, all intaQt installations come with a Server.conf file that contains commented-out configuration blocks for the most commonly-used configurations. Additional configuration blocks can be added to the Server.conf file, or additional configuration files can be created. An exception to this is that certain applications external to intaQt (for example, the intaQt Phone Service), require their own configuration files. This information is specified within the manual wherever applicable.

Important!

  • When updating a configuration file, the changes must be saved for intaQt to recognize them. However, if updating a .conf file within intaQt Studio, the file is automatically saved.

  • intaQt may need to restart after updating a non-reconfigurable block. All configurations are listed on an HTTP endpoint, (default localhost:8080/info). Files listed as "reconfigurable": false are non-reconfigurable.

General Configuration
Default Server.conf Configurations
Hierarchical Configuration
Activate and Deactivate Configurations
Absolute and Relative Paths
Additional Configuration Folders
Configuration File Management

Activate and Deactivate Configurations

A configuration block may be deactivated by typing an underscore (_) before it. Deleting an underscore that precedes the configuration will activate it.

Deactivated Configuration Example

1
2
3
_HttpServer  {
    port = 8080
}

Activated Configuration Example

1
2
3
HttpServer  {
    port = 8080
}

Default Server.conf Configurations

By default, a Server.conf file is created and contains commented-out configuration blocks for the most commonly-used configuration. Removing the # allows intaQt to recognize them.

Commented-out Default Configuration Block Example

1
2
3
4
#Platform {
#    locale   = "en_US"
#    timeZone = "UTC"
#}

Non-commented-out Configuration Block Example

1
2
3
4
Platform {
    locale   = "en_US"
    timeZone = "UTC"
}

Hierarchical Configuration

intaQt configuration files are loaded in a hierarchical manner to make test cases in different environments more maintainable.

Given a test case in the folder/subfolder of a project, the configuration will be loaded the following way:

  • intaQt configuration is used as a basis

  • The configuration files that reside in the project's root folder are merged

  • The configuration files located in a project's folder are merged

  • The configuration files located in a project's folder/subfolder are merged

Nested properties are merged recursively, but Atomic properties override previous values. The same is true when a sub folder's configuration is merged with a parent folder's configuration.

Example

Assuming the following configuration is configured at the intaQt level:

1
2
3
4
5
6
7
ContextObjects {
    "a" : 4,
    "b" : {
        "c" : 1
    }
    "d" : { "e" : "foo" }
}

And the following configuration is configured at the project level:

1
2
3
4
5
6
7
ContextObjects {
    "a" : 5,
    "b" : {
        "d" : 2
    }
    "d" : "bar"
}

The second configuration (project configuration) will be merged into the first one (intaQt configuration), resulting in:

1
2
3
4
5
6
7
8
ContextObjects {
    "a" : 5,
    "b" : {
        "c" : 1,
        "d" : 2
    }
    "d" : "bar"
}

Absolute and Relative Paths

Certain configurations include a Path that points to a location. For example, a folder that stores templates used by intaQt.

  • Unless specified otherwise, the path may be an Absolute Path or a Relative Path.

Relative paths inside configuration files are resolved relative to the project root. intaQt's behavior is as follows:

  • If path is absolute, use absolute path.

  • If relative, resolve it from project root.

  • If it does not resolve from project root, try it relative to the working directory.

Absolute Path Example

1
"/Users/qitasc/myprojects/uisteps"

Relative Path Example

1
2
"../dirOutsideProject/languageDir"
}

Error Messages

If a path is configured incorrectly, intaQt should shutdown upon startup and will produce an error in the log output that specifies the configuration and its incorrect path.

Example

1
2
| configure error
java.lang.RuntimeException:  * Selenium.apksPath: directory doesn't exist "/Users/qitasc/myprojects/uisteps/apks"

Additional Configuration Folders

Additional folders to read configurations from can also be specified. The file path must be defined in the ConfigurationFolders block.

Important! intaQt must be restarted after making changes to this configuration.

Syntax

1
2
3
ConfigurationFolders {
folders = [<pathToFolder String>, ...]
}

Parameter

  • pathToFolder - Points to the folder that holds additional configurations

Example

1
folders = ["C:/yourFolder/yourConfigFolder", ...]

Configuration File Management

Because ContextObjects, CdrVerificationConfigurations and Subscribers configuration blocks can become quite long, it is recommended to split the Server.conf into thematically sorted .conf files in addition to the main server.conf. For example:

  • Subscriber.conf file for mobile subscribers

  • Snom.conf for Snom phones

  • AndroidDevices.conf for SIM Array phones

  • ContextObjects.conf to store Context Objects

  • Cdr.conf to contain Verification configurations for:

    • CdrVerificationFtps
    • CdrVerificationVariables
    • CdrVerificationConfigurations