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.
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