Introduction

Connecting to DTP allows you to obtain the network license and extend team-working capabilities, such as:

• Reporting analysis to a centralized database (see Sending Results and Publishing Source Code to DTP)
• Sharing test configurations
• Sharing static analysis rules

In addition, DTP aggregates and prioritizes data collected from analysis tools, as well as performs additional analysis to help you optimize development processes; see About the Parasoft Development Testing Workflow for details.

Configuring Connection to DTP Server

The connection must be configured in the .properties configuration file (see Configuration Overview). Set the following properties to configure the connection:

• dtp.url=[URL] 
• dtp.user=[USER]
• dtp.password=[PASSWORD]

Creating an Encoded Password

dotTEST can encrypt your password, which adds a layer of security to your interactions with DTP Server. Run the following command to print an encoded password:  

-encodepass [MYPASSWORD]

Copy the encoded password that is returned and paste it into the dottestcli.properties file:

dtp.password=[ENCODED PASSWORD]

Configuring OpenID Connect in the .properties File

DTP ships with support for OpenID Connect user authentication (see the DTP User Guide for details). If OpenID Connect is enabled for your DTP server, you must configure dotTEST to authenticate users via OpenID Connect.

Configure the following settings in the .properties file where the connection to your DTP server is configured.

If device code authentication will be used (default):

• oidc.enabled=true
• oidc.cli.mode=devicecode[method that will be used to authenticate the user on the OpenID Connect server. See Using Device Code Authentication]
• oidc.issuer.uri=[URI of the OpenID Connect server]
• oidc.client.id=[ID provided by the OpenID Connect server]
• oidc.devicecode.token.file=[path to the custom token file containing user authentication information]

If certificate authentication will be used:

• oidc.enabled=true
• oidc.cli.mode=certificate[method that will be used to authenticate the user on the OpenID Connect server]
• oidc.issuer.uri=[URI of the OpenID Connect server]
• oidc.client.id=[ID provided by the OpenID Connect server]
• oidc.client.secret=[password provided by OpenID Connect server]
• oidc.keystore=[path to the keystore file that stores the certificate to authenticate the user on the OpenID Connect server]

• oidc.keystore.password=[password to the keystore file; we highly recommend that you use an encoded password; see Creating an Encoded Password.]

See OpenID Connect Settings for details.

Using Device Code Authentication

If "devicecode" mode is enabled, the verification URI with user code is printed on the dotTEST console. The user must use this URI and code to authenticate. If the authentication is successful, the information is saved to a token file (the path to the file is stored in the oidc.devicecode.token.file setting) and reused each time dotTEST is run. If the information saved in the file becomes invalid, the user will need to authenticate again.

About the Parasoft Development Testing Workflow

In addition to providing licensing and shared assets for testing and analyzing your software under development, Parasoft DTP collects and merges data points from Parasoft tools, third-party analysis tools, and external systems, such as bug tracking and requirements tracking systems. It aggregates and prioritizes data, as well as performs additional analysis to help you optimize development processes. Using your code analysis and test execution tool with DTP enables you to consistently apply quality practices across teams and throughout the SDLC.

The following illustration shows the general workflow.

Integrating Parasoft Tools with the Build

Parasoft tools ship with plugins for integration with your build tools (i.e., Maven, Ant, Gradle, MS Build, make, etc.). These integrations allow you to analyze code and send data to DTP automatically as part of the automated build processes and continuous integration (CI).

Capturing Observations

When the analysis tool is running, it captures massive amounts of detailed data associated with the code referred to as “observations.” Observations are code quality data, such as static analysis violations, unit test failures, metrics, etc., as well as logistical information about the code, such as authorship, scope, and source control location. 

Converting Data into Findings

When observations are sent to DTP, they are converted into “findings” and stored in the database. Findings are observations that have been analyzed, normalized, and aggregated into actionable data. 

Importing DTP Findings to the Desktop

You can import priorities and filtered findings from DTP directly into your IDE so that issues can be addressed.

Continuing the Cycle

When you check code back into source control, the continuous integration process picks up the change, and the workflow is repeated. This ensures that defects are detected and prevented from becoming software bugs later in the development process when the costs of remediation are much higher.