In this section:

Filtering Recommendations

Recommendations for test improvements are displayed in the Recommendations view after tests are executed (see Configuring Preferences for information how to specify which recommendations UTA will generate). By default, all recommendations generated during the run are displayed, but you can filter out specific recommendations by selecting a category from the drop-down menu at the top of the Recommendations view:

Using Action Links

Recommendations include action links that help you navigate the test code and introduce changes. The action links that are displayed for each recommendation may vary depending on the recommendation type, the test type, and the test code. However, all recommendations include:

• Go to - Highlights the code associated with the recommendation in the editor.
• Highlight - Highlights the issue in the execution flow displayed in the Unit Test Assistant View.

Recommendations can also include:

• the Learn more... link which opens a page with details about individual recommendations,
• the Track[method_name] action link which detects values that may need to be asserted; see Tracking Object Changes and Creating Assertions for more information,
• action links that automatically update your test code (for example, Uncomment removes specific comment markers in test templates generated by UTA, and Remove Assertion deletes the line with an unnecessary assertion).

Working with Recommendations

This section shows several examples of Unit Test Assistant recommendations and how they can be used to improve the quality of your test.

No Assertions

UTA detected that the test does not contain any assertions. Typically, this may happen when you create a new test with UTA and leave the default UTA assertions commented.

Remedy: You can do one of the following:

• Uncomment the default assertions manually or with the Uncomment action link and modify the default values.
• Click the Track[method_name] action link. UTA will run the test and display the values that may need to be asserted; see Tracking Object Changes and Creating Assertions for more information.
• Manually modify the test and make assertions based on the green and red coverage markers that indicate the test execution flow.

Assertion Failure

UTA detected an assertion that failed during the test run, because the asserted value was different than expected.

Remedy: You can do one of the following:

• Manually modify the assertion in the test code.
• Click the Update Assertion action link to automatically replace the current value with the expected one.
• Click the Invert Assertion link to automatically invert the assertion logic, for example, by replacing assertTrue with assertFalse.
• Click the Remove Assertion link to remove the assertion from the test code.

If you run a Spring test, the Invert Assertion action link is not available. Depending on the assertion type, you can automatically update your test using one of the following action links:

• Update Assertion replaces the current value with the expected one. If the value to be updated is assigned to a local variable, the action link is available only if the value types match (for example, both values are of integer type).
• Update status to: [...] updates the HTTP Status assertion.
• Remove Assertion removes the assertion from the test code.

System Properties Changed

UTA detected a system property that was added during the test run, but was not removed after execution. As a result, all subsequent tests will have access to that property, which may create dependencies between tests and prevent you from running them in isolation. 

Remedy: Ensure that the system properties that were added or modified during a test run are removed or restored after execution.

Additional Threads

UTA detected an additional thread that was active during the test run. Additional threads may affect test stability and cause random failures.

Remedy: Avoid writing test cases with side threads or ensure that they do not affect test results.

New Files Created

UTA detected a new file that was created during the test run, but was not removed after execution. This may affect subsequent test runs or other tests, as well as hide potential problems within the application, such as resource leaks.

Remedy: Ensure that the files created by the test are removed before the end of the test run.

Static Fields Changed

UTA detected a static field that was modified during the test run. This may affect subsequent test runs, as well as other tests.

Remedy: Avoid writing test cases that change static fields during execution or ensure that the changes do not affect test results.

Timeout

The time limit that was specified when multiple tests were created (see Creating Multiple Unit Tests) has been exceeded. 

Remedy: Manually modify the test to reduce its execution time or set a new timeout by modifying the value in the test code:

Uncovered Code

UTA detected code that is not covered. Click Go to navigate to the uncovered code.

Remedy: You can do one of the following:

• Modify or extend an already existing test case to cover the code. For example, you may need to modify the method parameters.
• Manually copy an existing test case, and then modify the duplicate to cover the code.
• Click the Clone test action link to display a list of existing test cases that have been executed; then select a test case you want to duplicate and modify.  UTA preselects a test case to clone based on the test case coverage and name (if the coverage is identical, UTA selects the test case with the highest consecutive number in its name). This quick fix is available only for regular tests.

UTA may display hints how the test case should be modified to cover the code.

Recommendation Types

See Recommendation Types for information about the types of recommendations UTA can display.