In this section:

Overview

Test configurations define how your code is analyzed and tested, including which static analysis rules are enabled, which tests to run, and other analysis parameters.Jtest ships with built-in test configurations, but users can create and store their own test configurations in the DTP server (see the DTP documentation for details).

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 jtestcliwith 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.
MetricsComputes values for  several code metrics. 
Critical RulesIncludes most Severity 1 rules, as well as rules in the Flow Analysis Fast configuration.  
Flow Analysis StandardDetects 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 2011Includes rules that find issues classified as Top 25 Most Dangerous Programming Errors of the CWE-SANS standard.
CERT for JavaIncludes rules that find issues identified in the CERT standard.
OWASP Top 10 2017Includes 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.
UL 2900 Includes rules that find issues identified in the UL-2900 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, 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