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
-configswitch 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
-configoption 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: Settings Property Pattern<config>user://Configuration Name</config>
jtest.config=user://Configuration Name
Viewing Available Test Configurations
Use the Use arguments to filter configurations; the use of "*" expressions is supported-listconfigs switch to print the available test configurations. -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 Configuration Description Recommended Rules The default configuration of recommended rules. Covers most Severity 1 and Severity 2 rules. Includes rules in the Flow Analysis Fast configuration. Find Duplicated Code Applies static code analysis rules that report duplicate code. Duplicate code may indicate poor application design and lead to maintainability issues. Internationalize Code Applies static code analysis to expose code that is likely to impede internationalization efforts. Juliet 1.1 2011 Metrics Computes values for several code metrics. New Features in JDK 1.5 New Features in JDK 7 DISA-STIG for Java Includes rules that find issues identified in the DISA-STIG standard Critical Rules Includes most Severity 1 rules, as well as rules in the Flow Analysis Fast configuration. Flow Analysis Standard Detects 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 Aggressive Includes rules for deep flow analysis of code. Significant amount of time may be required to run this configuration. Flow Analysis Fast Includes rules for shallow depth of flow analysis, which limits the number of potentially acceptable defects from being reported. Demo Configuration Includes rules for demonstrating various techniques of code analysis. May not be suitable for large code bases. Find Memory Problems Includes rules for finding memory management issues in the code. Find Unused Code Includes 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. CERT for Java Includes rules that find issues identified in the CERT standard SAMATE NIST 2010 Includes rules that find issues identified in the NIST SAMATE standard OWASP Top 10 [2007, 2010, 2013, 2017] Includes rules that find issues identified in OWASP’s Top 10 standard PCI Data Security Standard Includes rules that find issues identified in PCI Data Security Standard Thread Safe Programming Rules 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 Tests Includes the unit test execution data in the generated report file Calculate Application Coverage Processes the application coverage data to generate a coverage.xml file. See Application Coverage. Unit Testing Best Practices Helps you enforce unit testing best practices and ensure that assertions are made in your unit tests Code Smells Rules based on the Code Smells document (available at http://xp.c2.com/CodeSmell.html) by Kent Beck and Martin Fowler. TDD The 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 Assistant Includes 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.
