In this section:
Jtest runs on jtest.data.json data files that are automatically generated by the build system plug-ins. Alternatively, you can manually create a JSON file; see Creating Custom .json Data Files for details.
The JSON file determines the primary testing scope. You can narrow down that scope by using the resource, include, and exclude options.
If a pattern is specified with the resource or include option, resources that do not match this pattern are automatically excluded from analysis.
resource optionYou can modify the scope by specifying the resource pattern with one of the following:
the -resource command line option (you can use multiple -resource switches to specify multiple resources)
-resource [pattern] |
the jtest.resource setting in the .properties file (separate multiple resources with a comma); see Configuration Overview for details.
jtest.resource=pattern1,pattern2 |
the Maven or Ant <resource> pattern:
<resources>
<resource>pattern1</resource>
<resource>pattern2</resource>
</resources> |
The general syntax of the resource pattern is:
[project name]/[resource path relative to the project] |
You can use Ant-style wildcards and other parameters to specify patterns:
| Parameter | Description |
|---|---|
? | Wildcard that matches one character (any character except path separators) |
* | Wildcard that matches zero or more characters (not including path separators) |
** | Wildcard that matches zero or more path segments. |
/ | Separator for all operating systems |
"[non-alphanumeric characters]" | Use quotation marks when resource paths contain spaces or other non-alphanumeric characters. |
If the -resource argument only contains one value, the value is matched against the project name and a wildcard (*) will be used. The following table shows examples of -resource switch usage.
| Expression | Result |
|---|---|
-resource ProjectName/src | Analyzes every file in the selected directory and subdirectories (without wildcards, the complete name of the folder has to be specified). |
-resource ProjectName/**/*.java | Analyzes every Java file from selected project. |
-resource **/src/main/java/my/company/*.java | Analyzes every Java file from the specific subdirectory of every project in current build. |
-resource ProjectName/src/main/java/my/company/File.java | Analyzes the single specified resource. |
-resource c:/resource.lst | Analyzes the projects listed in the |
The ProjectName value is generated according to following rules:
You can customize the Maven and Gradle project names with the projectNameTemplate parameter. See Jtest Goals Reference for Maven and Jtest Tasks Reference for Gradle.
Generated paths include the EXT string if the specified scope includes external resources. For example, an analyzed project may include source files from another location that are linked to the project. In the following example the Simple.java file is located within the Demo project, whereas the Money.java file has been added by linking and its location is outside of the project:
Demo/src/main/java/examples/eval/Simple.java Demo/EXT/examples/bank/Money.java |
include and exclude OptionsYou can modify the scope by specifying the include and/or pattern with one of the following:
the -include and -exclude command line options
-include pattern -exclude pattern |
the jtest.include and jtest.exclude settings in the .properties file; see Configuration Overview for details.
jtest.include=pattern jtest.exclude=pattern |
the Maven or Ant <resource> pattern
<include>pattern</include> <exclude>pattern</exclude> |
If both include and exclude patterns are specified, Jtest analyzes the resources specified with the include option, except the resources that match the exclude pattern.
The include or exclude pattern can be defined by specifying one of the following:
path: [absolute path on disc]You can use Ant-style wildcards and other parameters to specify patterns:
| Parameter | Description |
|---|---|
? | Wildcard that matches one character (any character except path separators) |
* | Wildcard that matches zero or more characters (not including path separators) |
** | Wildcard that matches zero or more path segments. |
/ | Separator |
| path: | Prefix for matching absolute disk path |
You can specify a file system path to a list file (*.lst) to include or exclude files in bulk. Each item in the *.lst file is treated as a separate entry.
| Usage | Description |
|---|---|
-include com/** | Tests everything in packages that begin with "com". |
-include path:**/Bank.java | Tests only Bank.java files |
-include path:C:/Project/src/** | Tests all subfiles and subdirectories of C:/Project/src |
-include path:C:/Project/src/* | Tests all files in C:/Project/src, but not subdirectories |
-include c:/include.lst | Tests all files listed in |
-exclude **/internal/** | Tests everything except classes that have "internal" as part of the package name. |
jtest.includeTestSources OptionYou can modify the scope by including test source code in the analysis with the jtest.includeTestSources command line option:
-Dproperty.jtest.includeTestSources=true |
This option is disabled by default. (In the IDE, test source code is included in the analysis by default.)
Note: This option does not work for Jtest Plugin for Ant.
In typical scenarions, Jtest runs on jtest.data.json data files that are automatically generated by build system plugins. Alternatively, you can manually create a .json file and provide Jtest with the path to that file using the -data command line option (see Running Static Analysis).
To manually create a data file Jtest will use for analysis, run jtestcli with the -project options. By default, an example.data.json file is created in the root of the project configured with the -project.location option, but you can customize the location and name of the .json file using -project.jsonpath.
See Creating a Custom JSON for the list of available options.
You can restrict the scope of analysis to locally modified files or to files modified on the current working branch by setting up additional file filters. This allows you to focus on identifying and fixing bugs introduced by your recent code changes before the code is checked in your source control system or merged with the main development stream.
While modifying the default scope allows you to speed up analysis, it may impact violations reported by rules that require information about other resources included in the project. In particular, rules that analyze execution paths, calculate metrics, or check for duplicate code may be prone to reporting false positives or negatives if they have no access to files excluded from the scope. For this reason, we recommend that you regularly perform full-scope analysis to ensure that all rule violations are detected. One example scenario is that a limited scope is analyzed when working with Jtest on the desktop, while a full-scope analysis is performed during automated builds on a server. |
scope.scontrol=true setting must be configured to enable computing authorship based on your source control system (see Scope and Authorship Settings).To narrow down the scope of analysis to files that are locally modified, add the following option in your .properties configuration file:
scope.scontrol.files.filter.mode=local |
To narrow down the scope of analysis to files on the current working branch that differ from the main integration stream, such as "master" or "trunk", add the following option in your .properties configuration file:
scope.scontrol.files.filter.mode=branch |
If you want to compare your working branch with another branch or with a specific revision rather than the main integration stream, you need to provide the name or ID of the branch or revision you want to use as reference. The following configuration narrows down the scope of analysis to files on the current working branch that differ from a custom branch/revision:
scope.scontrol.files.filter.mode=branch scope.scontrol.ref.branch=[name/ID of the custom reference branch/revision] |
The scope filter settings configured in the .properties file affect all test configurations.
See Scope and Authorship Settings.
Alternatively, you can define additional scope filters in the test configuration by creating a custom test configuration and specifying the filter you want to apply, see Creating Custom Test Configurations. The scope filter settings configured in the GUI only affect the given test configuration and are overridden by scope filter settings configured in .properties file.