This topic explains how to configure Unit Test Assistant.

In this section:

Configuring General Options

To configure the general UTA options, choose Parasoft> Preferences> Unit Test Assistant.

Test source folder

This option allows you to specify the root directory where tests created with UTA are saved. By default, the option "[ Based on project configuration ]" is selected which will read the project's settings to determine where tests should be saved. If the project does not specify where tests are located, then either update your project's configuration so a test source folder is specified, switch to one of the predefined patterns, or create a pattern manually using the following variables:

${project_name} - The name of the project (module for IntelliJ) that includes the tested class.
${source_folder} - The name of the folder that contains the source files of the project.

Test class name pattern

This option allows you to specify the package and class name pattern for tests. The default pattern of "${package_name}.${class_name}${test_kind}Test" will put tests in the same package as the class being tested and add "${test_kind}Test" suffix to the class name. A custom pattern can also be specified using the following variables:

${class_name} - The name of the tested class.
${package_name} - The name of the package that includes the tested class.
${test_kind} - The name of the test type, which will be added to the file name. This variable can take the following values:
          - Spring - Separates Spring tests from other tests in JUnit 4 and 5.
          - Parameterized - Separates parameterized tests from regular tests in JUnit 4. In JUnit 5, regular and parameterized test cases are added to the same file.

For tests that are not Spring or parameterized tests, the ${test_kind} variable resolves to empty string.

Testing framework for new tests

This option allows you to specify the testing framework UTA will use to create new tests. You can choose JUnit 4 or JUnit 5.

Test creation options

Create tests for private methods

This option allows you to enable creating unit tests for private methods. When enabled:

• the Unit Test Assistant view displays action links that allow you to create unit tests for private methods when a private method is selected in the editor (see Creating Tests for Private Methods).
• if you are creating tests with the Create test suite option for a single class, the private methods are available to be selected in the dialog (see Creating a Test Suite for One File).
  
• if you are creating tests with the Create test suite option for multiple classes, tests are automatically created for the private methods (see Creating a Test Suite for Multiple Files).
  

Configure tests with timeout (in ms)

This option allows you to specify the time limit (in milliseconds) for executing a test suite created with the Create test suite option. If the time limit is exceeded, the test execution will stop, the test suite will fail, and the information about the error will be displayed as a Recommendation in the UTA interface. See Creating Test Suites.

Generate sample assertions

With this option enabled, UTA automatically generates assertion templates as comments in code when a basic test case is created. See Creating a Basic Unit Test for details.

Only add test cases that increase coverage

With this option enabled, only test cases that increase coverage are added during bulk creation (see Creating a Test Suite for Multiple Files).

Factory methods options

Automatically discover tagged factory methods

With this option enabled, UTA:

• scans all projects for factory methods on the IDE startup.
• searches for updates to factory methods when your project is modified (for example, when you create or delete a Java file or project).

See Configuring Factory Methods for details. 

Parameterized tests

Enable creation actions

With this option enabled, UTA displays action links that allow you to create parameterized test cases. See Creating a Parameterized Unit Test.

Parameterized tests depend on the testing framework you configured with the Testing framework for new tests option:

• For JUnit 5, JUnit 5 Parameterized is automatically enabled.
  
• For JUnit 4, you need to select the framework for creating parameterized test cases.
  
  

Advanced Settings

Advanced settings allow you to configure input data for creating parameterized test cases.

The maximum number of parameter sets created for one test case 

This option specifies the maximum number of rows with parameter variants that will be created for one test case.

Generate test data to

This option specifies where the test cases are saved. You can choose Code (default) or CSV from the drop-down menu.

Parameterization values

This set of options allows you to customize the default list of values by selecting a data type from the Select type drop-down menu and adding, editing, or removing the values in the list. The Find field allows you to conveniently search for a particular value.

Spring framework tests

Enable creation actions

With this option enabled, UTA displays action links that allow you to create Spring test cases. See Creating a Spring Unit Test.

Default ContextConfiguration attributes

This option allows you to specify the attributes to be included in the ContextConfiguration annotation when a Spring test is created. See Configuring Spring tests with the ContextConfiguration Annotation.

Configuring Execution Monitor Options

Configuring UTA execution monitor options allows you to specify the limits for collecting data during test execution. In addition, to prevent exceeding the limits, you can specify packages and classes you want to exclude from monitoring when executing tests with UTA.

To configure the mocking options for UTA options, choose Parasoft> Preferences> Unit Test Assistant> Execution Monitor.

Excluded packages and classes

This option allows you to specify a list of packages and classes to be excluded from monitoring. Click New and provide a qualified name of a package or class (wildcards are not supported).

Execution flow data collection limits

This set of options allows you to specify the limits for collecting data during execution:

• Maximum method call depth - Specifies the maximum depth of method calls during analysis.
• Maximum number of method calls made from a single method - Specifies the maximum number of sub-method calls from a single method.
• Maximum total number of method calls -  Specifies the maximum number of all method calls during analysis.

Configuring Mocking Options

To configure the mocking options for UTA options, choose Parasoft> Preferences> Unit Test Assistant> Mocking.

Enable

This option enables or disables mocking objects during test creation and execution.

Use helper methods for mocks

This option enables or disables using helper methods. If enabled, generated tests classes will separate regular test methods from helper methods that prepare objects but do not make assertions. 

Enable static method and constructor mocking (Mockito inline 3.5+ required)

UTA automatically mocks methods which match the patterns specified in the table. Click New to add a new method or pattern. Use qualified method names and wildcards (*) to match patterns. The patterns that end with .* or  <init> will be matched with constructors. For example, the following configuration will mock:

• all constructors in all classes whose names end with "Service".
• all static methods and constructors in all DAO classes in all sub-packages of "com.example".
• all methods of the InternalUtil class.

If the specified pattern matches all methods of a class, UTA will use the mockStatic() method to mock static methods of a class. For details about the mockStatic() method, see mockStatic.
Only the static methods and constructors specified in the table will be mocked. UTA will automatically add mocks to test templates during test creation, or display recommendations that will help you add mocks after your tests are run (see Creating Mocks).

Configuring Recommendations

You can specify which type of recommendations UTA displays after test execution.

To configure UTA recommendations, choose Parasoft> Preferences> Unit Test Assistant> Recommendations.

You can enable or disable the following recommendation types:

• Additional threads - detects side threads, which may impact the state of your test.
• Assertions for inaccessible fields - detects inaccessible fields that have been modified during execution and generates assertion templates.
• Files created - detects files that were created during the test run, but were not removed after execution.
• Mockable invocations - detects calls to mock objects that can be modified to ensure proper test isolation.
• Mockable static invocations - detects calls to the static methods that are configured to be mocked (see Configuring Mocking Options)
• No assertions - detects when no assertions have been made.
• Static fields changed - detects when static fields have been modified during test execution.
• System properties changed - detects system properties that were modified during the test run, but not restored after execution.
• Uncovered code - detects uncovered blocks of code.

See Executing Unit Tests with Unit Test Assistant for examples of recommendations displayed by UTA.

Configuring Test Templates

Test templates allow you to control the structure of test classes in order to specify common configurations that are required for your particular tests. For example, you can add setup methods or extend from a base class. 

To configure UTA test templates, choose Parasoft> Preferences> Unit Test Assistant> Test Templates.

• New - creates a new template and opens the template for editing. The Parasoft default template will be automatically provided.
• Edit - opens the template for editing.
• Remove - deletes a template. An error appears when you try to delete the active template or the last template.
• Mark active - is used to specify which template will be used for the quick add actions (non-bulk creation).

Edit Template

The Edit Template dialog makes allows you to create/edit a template.

The following must be configured in the Edit Template dialog:

• Template name: - the name of the template (unique).
• Class template - the source code for the class section of the template. Basic validation is performed during typing to check for errors in the template:
  • If a variable is malformed or not recognized, an error message ("Unknown or invalid variable") is shown. 
  • If the template fails basic syntax checking, an error is shown. 

The following variables are recognized:

• • ${className} - the unqualified name of the class being tested, for example: MyClass
  • ${qualifiedClassName} - the fully qualified name of the class being tested, for example: com.company.MyClass
  • ${author} - the username as specified in the DTP settings.
  • ${testClassName} - the unqualified name of the test being created, for example: MyClassTest
    The name is generated from the Test class name pattern and should not be changed in the template. The standard practice for updating the test class name is to update the Test source folder.

The following examples show the implementation of common class configurations.

Common base class extension:

import com.company.BaseTestClass;

public class ${testClassName} extends BaseTestClass
{
}

Adding setup/teardown methods for static mocking:

import org.junit.jupiter.api.*;
import static org.mockito.Mockito.*;
import java.util.*;

public class ${testClassName}
{
    Set<ScopedMock> staticMocks = new HashSet<>();

    @BeforeEach
    public void setup()
    {
        var mocked = mockStatic(MyUtilClass.class);
        staticMocks.add(mocked);
        mockUtil.when(MyUtilClass::getUserName).thenReturn("testUser");
    }

    @AfterEach
    public void teardown()
    {
        staticMocks.forEach(i -> i.close());
        staticMocks.clear();
    }
}

• Method template - the source code for new test methods. Basic validation is performed during typing to check for errors in the template:
  • If a variable is malformed or not recognized, or if a required variable is missing, an error message ("Unknown or invalid variable" or "Missing required variable in method") is shown. 
  • If the template fails basic syntax checking, an error is shown. 

The following variables are recognized

• • ${methodSignature} - the name of the tested method, including parameter types. For example: calc(int, int, String)

  • ${qualifiedMethodSignature} - the fully qualified name of the tested method, including parameter types. For example: com.company.MyClass#calc(int, int, String) 
    This variable is suitable for use in the @see tag of a Javadoc.

  • ${author} - the username as specified in the DTP settings.

  • ${testAnnotations} (required) - a placeholder for auto-generated annotations to be added to the test method. For example, JUnit tests need the @Test annotation. Custom annotations can be added before or after this variable.

  • ${testName} (required) - the auto-generated name of the test method.

  • ${testBody} (required) - a placeholder for auto-generated statements forming the body of the test. Custom code may be added before or after this variable to be included in all generated tests.

• Additional code can be added outside of the test method, but it is not recommended because it leads to duplicates. For instance, if the field "int foo = 0;" is added to the method template, the field will be added for each test and its name will be duplicated. Therefore, it is recommended to either include the ${testName} variable in the name of the added element, or add the code to the class template instead.

The following example shows a class and method template which defines and configures a field.

Class Template

public class ${testClassName}
{
    private CustomField customField = null;
} 

Method Template

${testAnnotations}
public void ${testName}() throws Exception
{
    customField = new CustomField(42, "Testing example");
    customField.init();

    ${testBody}
}