In this section:
Overview
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.
Modifying the Scope with the resource
option
You 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>
Syntax of the Resource Pattern
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. |
Examples
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 |
Resolving the Project Name
The ProjectName value is generated according to following rules:
- The Ant project name is taken from name property of project tag
- The Maven project name takes form of groupId:artifactId
- The Gradle project name is taken from gradle.settings file
- Project names configured in IDEs are fully maintained
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.
Handling External Resources
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
Modifying the Scope with the include
and exclude
Options
You 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
andjtest.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.
Syntax of the Include and Exclude Patterns
The include or exclude pattern can be defined by specifying one of the following:
- fully-qualified name of the resource(s)
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.
Examples
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. |
Modifying the Scope with the jtest.includeTestSources
Option
You 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.
Creating Custom .json Data Files
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.
Defining File Filters Based on Source Control Data
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.
Prerequisites
- Connection to a supported source control system must be properly configured (see Connecting to Source Control and Source Control Settings).
- The
scope.scontrol
=true
setting must be configured to enable computing authorship based on your source control system (see Scope and Authorship Settings).
Analyzing Locally Modified Files
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
Analyzing Files Modified on the Current Working Branch
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.