Configuring Parasoft C++Test, dotTest and Jtest

A commonly used option for checking for Abstract Interpretation and Security violations are the Parasoft xTest tools.

Basic configuration

Configuring timeout values

The timeout in seconds can optionally be configured as a configuration property either on SERVER or PROJECT level. If this property is not configured in the SERVER.yaml or PROJECTS.yaml, the TICS default value of 12 hours is used. The example sets the timeout for CppTest to 3600 seconds, Dottest to 1800 seconds, and Jtest to 7200 seconds. Note the capitalization; this is to match the internals of TICS.

    TIMEOUT: 3600
    TIMEOUT: 1800
    TIMEOUT: 7200

Note as well that this timeout is specified for a single invocation of the tool. In the case that the tool works on the solution level (Dottest) or per buildfile (Jtest), then each invocation of these tools will get the specified timeout. For instance, in the case of a C# project, you may have multiple solution files contained in the project. Dottest is run once per solution file, since it analyzes everything in its solution context. Therefore, configuring a timeout for Dottest will mean that this timeout holds for each one of these runs on a single solution file.

Configuring custom compiler configuration directory for C++Test

In certain cases, it is required to use a C++Test compiler configuration that is not provided by C++Test. Therefore, it should be possible to place a custom compiler configuration for C++Test in a directory outside the default C++Test compiler configuration directory (chk\cpptest\bin\engine\etc\compilers). TiCS provides a property for configuring this custom compiler configuration directory for C++Test. This property is called CUSTOMCONFIGDIR and can be configured under the property TOOLS => CppTest in SERVER.yaml. The value of this property should be a relative path with TICS viewer's <section root>/ticsfs/cfg/<your configuration> directory as the base directory, as shown in the examples below:

    CUSTOMCONFIGDIR: cpptestconfigs
    CUSTOMCONFIGDIR: ../common/cpptestconfigs

The CUSTOMCONFIGDIR property can also be applied on the PROJECT level, i.e. in the project-specific configuration file PROJECTS.yaml. If they are declared in the PROJECT level, they can be declared either inside or outside a branch name (inside VIEWS) of a project, as shown in the following examples:

project name:
      CUSTOMCONFIGDIR: cpptestconfigs
project name:
    branch name:
          CUSTOMCONFIGDIR: cpptestconfigs

If the property CUSTOMCONFIGDIR is declared both on the SERVER level, i.e. in SERVER.yaml, and also on the PROJECT level, i.e. PROJECTS.yaml, the project-specific properties will overwrite the global properties.

The custom compiler configuration directory should contain compiler configuration folders with the same name format as those available in the default C++Test compiler configuration directory, for example: clang_14_0, gcc_11 and gcc_11-64.

Configuring rule checkers in detail

For each one of these tools, a configuration file should exist in the TICS configuration directory:

Configuring parameterization via the .properties file

Parameterization of a rule can be done as follows in the .properties file. For instance, this block will run the checker BD-API-BADPARAM with the options reportUnvalidatedViolations and aggressiveMode:


Configuring parameterization via the IMPL.txt

The same can also be done via the TICS internal mechanism of the IMPL.txt file. To do parameterization in the IMPL.txt file, the following rules are used:

In practice, this looks like the following (for the same example as in the previous case):

BD-API-BADPARAM   CppTest   BD-API-BADPARAM=reportUnvalidatedViolations:true;aggressiveMode:true

Notes on the priorities of rule parameterization

For more details on these, refer to the section on IMPL.txt.

Configuring TICS to report out-of-date Parasoft licenses

By creating (or adapting) a EXPIRE.yaml file, the status of the Parasoft tools can be automatically checked and reported by TICS. This file can be placed in the TICS configuration directory (a default one with no contents is provided as part of a fresh TICS installation), and should have the following contents:

cpptest: 2021-01-01
dottest: 2021-02-02
jtest: 2021-03-03
with each one of the expiration dates in YYYY-MM-DD format. In that case, TICS will automatically report the license expiration date.