In this section:

Overview

Test configurations define how DTP Engines test and analyze code, including which static analysis rules are enabled, which tests to run, and other analysis parameters. Jtest DTP Engine ships with built-in test configurations, but users can create and store their own test configurations in the DTP server. You can access the DTP server via the DTP plug-in. If you have administrator-level access in DTP Report Center, you can also create test configurations directly in DTP (administration> Engines> Test Configurations). 

User-defined test configurations that are stored in DTP can be downloaded from the DTP server and stored in the [INSTALL_DIR]/configs/user directory as *.properties files. 

Running a Test Configuration

You can specify which configuration will be run in one of the following ways:

  • Run jtestcli with the -config switch and specify a built-in, user-defined or  DTP-hosted  test configuration:

    -config "builtin://Recommended Rules"
-config "user://Foo Configuration"
-config "dtp://Foo Team Configuration" 
-config "dtp://FooTeamConfig.properties"

    You can also provide a path or URL to the test configuration .properties file:

    -config "C:\Devel\Configs\FooConfig.properties"
-config "http://foo.bar.com/configs/FoodConfig.properties"


    For example, your command line may resemble the following:

    jtestcli -config "user://Configuration Name"

  • In the .properties file, specify the default configuration that will be run when the -config option is not used:

    jtest.config=user://Configuration Name

Ant and Maven Pattern

If you use Ant or Maven, you can specify the test configuration with the following pattern:

<config>user://Configuration Name</config>

Settings Property Pattern

jtest.config=user://Configuration Name

Viewing Available Test Configurations

Use the -listconfigs switch to print the available test configurations. 

Use arguments to filter configurations; the use of "*" expressions is supported

  • -listconfigs - prints all available configurations

  • -listconfigs builtin - prints all built-in configurations

  • -listconfigs builtin*Secure* - prints all built-in configurations that contain "secure" in the name

Built-in Test Configurations

The following table includes the test configurations shipped in the [INSTALL]/configs/builtin directory.

Built-in Test ConfigurationDescription
Recommended RulesThe default configuration of recommended rules. Covers most Severity 1 and Severity 2 rules. Includes rules in the Flow Analysis Fast configuration. 
Find Duplicated CodeApplies static code analysis rules that report duplicate code. Duplicate code may indicate poor application design and lead to maintainability issues.
Internationalize CodeApplies static code analysis to expose code that is likely to impede internationalization efforts.
Juliet 1.1 2011
MetricsComputes values for  several code metrics. 
New Features in JDK 1.5
New Features in JDK 7
DISA-STIG for JavaIncludes rules that find issues identified in the DISA-STIG standard
Critical RulesIncludes most Severity 1 rules, as well as rules in the Flow Analysis Fast configuration.  
Flow AnalysisDetects complex runtime errors without requiring test cases or application execution. Defects detected include using uninitialized or invalid memory, null pointer dereferencing, array and buffer overflows, division by zero, memory and resource leaks, and dead code. This requires a special Flow Analysis license option.
Flow Analysis AggressiveIncludes rules for deep flow analysis of code. Significant amount of time may be required to run this configuration.
Flow Analysis FastIncludes rules for shallow depth of flow analysis, which limits the number of potentially acceptable defects from being reported.
Demo ConfigurationIncludes rules for demonstrating various techniques of code analysis. May not be suitable for large code bases.
Find Memory ProblemsIncludes rules for finding memory management issues in the code.
Find Unused CodeIncludes rules for identifying unused/dead code.
CWE-SANS Top 25 [2009/2011]Includes rules that find issues classified as Top 25 Most Dangerous Programming Errors of the CWE-SANS standard.
SAMATE NIST 2010Includes rules that find issues identified in the NIST SAMATE standard
OWASP Top 10 [2007, 2010, 2013]Includes rules that find issues identified in OWASP’s Top 10 standard
PCI Data Security StandardIncludes rules that find issues identified in PCI Data Security Standard
Thread Safe ProgrammingRules that uncover code which will be dangerous to run in multi-threaded environments— as well as help prevent common threading problems such as deadlocks, race conditions, a missed notification, infinite loops, and data corruption.
Unit TestsIncludes the unit test execution data in the generated report file
Calculate Application CoverageProcesses the application coverage data to generate a coverage.xml file. See Application Coverage.
Unit Testing Best PracticesHelps you enforce unit testing best practices and ensure that assertions are made in your unit tests
Code SmellsRules based on the Code Smells document (available at http://xp.c2.com/CodeSmell.html) by Kent Beck and Martin Fowler.
TDDThe TDD (Test Driven Development) configuration includes rules based on the Code Smells document (available at http://xp.c2.com/CodeSmell.html), rules that check whether the JUnit test classes are comprehensive for the tested class, and rules from the Critical Rules (Must Have) Test Configuration.
Unit Test AssistantIncludes rules that help you improve the quality of your unit tests. We recommend using this test configuration in the CQA mode.


Creating Custom Rules

Use RuleWizard to create custom rules. To use the rule in the DTP Engine, it needs to be enabled in a test configuration and the custom rule file must be located in one of the following directories:

  • [INSTALL_DIR]\rules\user\
  • [DOCUMENTS DIR]\Parasoft\[engine]\rules where [DOCUMENTS DIR] refers to the "My Documents" directory in Windows.


  • No labels

Need assistance? Visit our support page