This section describes the test impact analysis workflow for Jtest desktop users. For information about test impact analysis from the command line, see Testing and Analysis with Maven and Testing and Analysis with Gradle.

In this section:

Introduction

Jtest's test impact analysis helps you optimize your testing efforts by automatically detecting test cases affected by modified code. This allows you to identify and re-run only the tests that are affected by your changes.

Jtest identifies unit tests impacted by code changes in the following ways:

• Code coverage data collected by Jtest during unit test execution. Specific code sections are correlated with the unit tests that execute that code.
• Unit test naming conventions. For example, if your modified class is named com.mypackage.MyClass, the test classes com.mypackage.MyClassTest, com.mypackage.MyClassParameterizedTest, and com.mypackage.MyClassSpringTest in the test source folder specified in the Unit Test Assistant preferences will be identified. If your modified method is named performFoo(), the test method testPerformFoo() will be identified.

The Impacted Unit Tests view will combine results from both ways of identifying tests.

Although the Impacted Unit Tests view will automatically display tests based on unit test naming conventions, the code coverage data provides more accurate results and will likely identify additional tests that need to be run. For this reason, it is recommended to ensure that code coverage data from your most recent full unit test run is imported into your IDE before reviewing Impacted Tests.

Requirements

Test impact analysis is available for projects that are stored in a version control system integrated with your IDE.

• Eclipse 4.23 (2022-03) or IntelliJ IDE 2022.1¹
• Git
• JUnit 4 or 5

¹ The Impacted Unit Tests view does not populate correctly when running in an IDE with Java 16 or later. See Known Limitations for information about the workaround.

Importing Coverage

For the most accurate results, ensure that coverage data related to the source code you modify is available in the Coverage View in your IDE. To achieve this, you need to integrate Jtest into your unit test execution to collect the coverage data in an XML file or report it to DTP, and then import the data to your IDE.

Information about correlations between tests and code persists between restarts of the IDE–even if the Coverage view does not display any coverage data after a restart. You can refresh correlations by re-importing coverage from a file or DTP to your IDE.

Importing From a File

The coverage.xml file is generated when you run unit tests with your build tool (Maven, Ant, or Gradle) integrated with Jtest on your CI server. You can choose the option to import the coverage data from the file if all your unit tests are executed in a single test run.

1. Integrate Jtest with your build system (see Integrating with Build Systems).

2. Configure your unit test execution job to collect coverage data with Maven, Gradle, or Ant. When the job runs, coverage for executed tests will be saved in a coverage.xml file in the job location on the server.
   Configure your job to save the file in a location from which it can be easily downloaded.

3. Import the coverage data from the file to your IDE using the Import from Local File or URL option (see Importing Coverage). You can download the file from your build server and then specify the path to the local file, or specify the URL to the file stored on your build server.

Importing from DTP

You can choose the option to import coverage data from DTP if there are multiple test runs you want to collect coverage for.

1. Enable connection with DTP (see Connecting to DTP).
2. Integrate Jtest with Maven, Ant, or Gradle (see Integrating with Build Systems).
3. Ensure Jtest is configured to send coverage data to DTP (see Sending Coverage Information to DTP).
4. Configure a unit test execution job(s). When the job runs, coverage data for executed tests will be sent to DTP and merged with data from previous runs.
5. Import the coverage data from the file to your IDE using the Import from DTP option (see Importing Coverage).

Monitoring and Running Impacted Tests

You can monitor and re-run tests impacted by your code changes in the Impacted Unit Tests view. To open the view, choose Parasoft> Show View> Impacted Unit Tests in your IDE menu bar.

Monitoring Impacted Tests

Jtest automatically monitors all open projects in the workspace. By default, the view displays in real time which tests are affected by your current code modifications – every time you make a code change that impacts a test, the view is refreshed to display that test. To switch off automatic detection of affected tests, disable the Auto-detect impacted tests option in the view's menu.

If the option is disabled, you need to manually refresh the view by clicking the Refresh button.

You can right-click a detected test and choose Go to to view the test code in the editor:

In addition, the Impacted Unit Tests view displays:

• the number of projects that contain impacted tests
• the total number of affected test methods and test classes
• the current status of the tests (Passed/ Failed/ Not run)

Running Impacted Tests

To run all impacted tests that are displayed in the view, click the Run all tests button in the view's menu.

To run a subset of impacted tests, select the project, package, class, and/or method node(s) to analyze and click Run selected in the view menu.

If tests fail when run from the Impacted Tests view, you can run and diagnose a single test. To do that right-click the test, and choose Run with Unit Test Assistant.

To stop the test execution, click the Stop button in the view's menu. 

Note: Non-public JUnit 5 test classes from a package other than the default package cannot be run in the Impacted Unit Tests view. They are shown in the view as unavailable.

Running Impacted Tests Continuously

The Run tests continuously button in the view's menu enables the continuous execution of all impacted tests and automatic collection of coverage data for them in the background. The tests will run each time the impacted tests tree is updated in the view (either when the Auto-detect impacted tests option is enabled or when the view is refreshed using the Refresh button).

The test status displayed in the view will be automatically updated after the tests are run.

Collecting Coverage 

To collect coverage for the Coverage view, select the Collect coverage option from the menu. This will enable the Coverage view to provide coverage data to the Impacted Unit Tests view, where it is used to correlate tests with the covered code.

Displaying Errors in the Findings and Finding Details Views 

If tests fail when run from the Impacted Tests view, their results and error stack traces will be displayed in the Findings and Findings Details views for analysis.

A list of findings is displayed in the Findings view.

The details of a single finding can be displayed in the Finding Details view.

Configuring Impacted Tests

To specify the scope of Git commits used to collect impacted tests, click the Configure link, and configure the settings in the Impacted test settings dialog.

• Modified methods 
  • When compared to - Tests will be displayed for all modified methods found when comparing the files on disk to their contents in the provided commit.
  • Since current branch diverged from - Tests will be displayed for all methods modified within the project's current branch since the branch diverged from a specified branch. The branch from which the current branch was created must be specified.
• Commit or branch - Allows you to specify a commit, branch, or tag used for the When compared to and Since current branch diverged from settings. The commit or branch dropdown menu stores the input history. It includes two preset values for the When compared to setting:
  • "Latest commit on local branch" - Tests will be displayed for locally modified, un-committed code.
  • "Latest commit on remote branch" - Tests will be displayed for locally modified, un-committed code as well as changes in any local commits that have not been pushed to a remote branch.

Note: 

• Git reflog references are not supported.
• If you encounter errors indicating that branches or commits are not found, first ensure your local Git repository is up to date.
• Consider the following recommendations for using the Modified methods and Commit or branch settings:
  • If you have local changes only and want to display tests for the impacted code pre-commit, we recommend using the "When compared to" and "Latest commit on local branch" settings.
  • If you have local commits that have not been pushed and you want to display tests for those commits, including any current local changes, we recommend using the "When compared to" and "Latest commit on remote branch" settings.
  • If you have pushed commits to a branch, such as a feature or development branch, and now that the feature or fix is complete, you want to display tests for all the changes made in the branch, we recommend using "Since current branch diverged from" and specifying the parent branch of the current one. For example, if you are using a feature branch "feature/foo" which was branched from master, you could specify "master".