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. 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 jtestcliwith 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:
<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 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. |
| Metrics | Computes values for several code metrics. |
| 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 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. |
| OWASP Top 10 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. |
| UL 2900 | Includes rules that find issues identified in the UL-2900 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, 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.
