This topic explains how to suppress static analysis violations in SOAtest. In this section:
Suppressions are special markers that enable you to run a test or follow a static analysis rule while ignoring specific occurrences of the reported tasks. Suppressing tasks related to functional testing can reduce the amount of noise tests generate during early-stage testing or for cases when then certain steps are expected to fail.
Suppressions for static analysis enables you to comply with programming guidelines by defining exceptions that do not impact the critical parts of the application. Multiple tasks may be reported for a single static analysis rule, but you can apply a suppression if the rule is not applicable for a particular case.
When you apply a suppression, a parasoft.suppress file is created in the same location as the test file. The suppression file includes information, such as which file has a suppression, the suppression author, and the reason for the suppression (see Manually Defining Suppression Files). Suppressed tasks are also removed from the Quality Tasks view.
Suppression settings are independent of Test Configurations. The Test Configuration defines the scope of the test execution, coverage settings, and other features, as well as the set of rules that are checked during static analysis. Suppressions define which tasks associated with a failing test or reported by static analysis results should be visible in Quality Tasks view and reports.
- Right-click on a reported task in the Quality Tasks view and choose Suppress Task.
You can also right-click on a node containing task (rule category, specific rule, file, etc.) to suppress all children tasks.
- Choose where you want to store your suppression(s) when prompted. Storing suppressions on Team Server is deprecated and disabled by default and will be removed in future versions. See Enabling Team Server Suppressions (Deprecated) for instructions.
- Enter your reason to for suppressing the task when prompted and click OK.
The task will then be suppressed and moved from the Quality Tasks view to a suppression file. The file will be created in the same directory as the test file. To review the suppression, open the file in the SOAtest editor or any plain text editor. See Manually Defining Suppression Files for additional information about the content of parasoft.suppress files.
Manually Defining Suppression Files
You can manually build the parasoft.suppress file by creating a text file in the same location as the test file and include suppression information in the following format:
The following table describes the fields supported in the parasoft.suppress file.
|Indicates the beginning of an individual suppression. All subsequent fields up to and including the
suppression-end field are part of the same suppression.
Specifies the name of the test file.
Specifies the line number in the code where the violation occurred.
This field applies to static analysis only.
Note that if the line number changes, i.e., updates to the code changes where the violation occurs, the suppression will become invalid.
Specifies the static analysis rule ID that reported the violation.
This field applies to static analysis only.
Specifies the test ID. This enables you to target specific tests within the test file to suppress. The test ID appears in the
This field applies to functional test execution.
|Specifies the message printed to the Quality Tasks view for the violation or test failure. The value must match the printed message exactly for the suppression to be valid. If the
message is specified but no matching message is reported, the suppression will be invalid.
Specifies the justification for suppressing the violation or test failure.
If it is determined that the task is reported as a false positive, begin the statement with
|Specifies the code or test author.
|Specifies the date the suppression was applied.
|Indicates the end of the suppression.
All properties specified in the suppression must match task properties for the suppression to be applied.
Example Suppression File
The following example shows a suppression file containing two functional test step suppressions:
Working with Deprecated Suppressions
Storing suppressions in the XML-style format locally or on Team Server is deprecated. Instead, suppressions are stored in the parasoft.suppress file. You can create suppressions using SOAtest's IDE functionality (see Suppressing Tasks) or by manually adding them to the parasoft.suppress file (see Manually Defining Suppression Files). Suppressions stored in deprecated format are still applied to your code and can be reviewed in the deprecated Suppressions view, but you can use the suppression migration functionality to transfer them to the parasoft.suppress file format.
Migrating Suppressions from Deprecated Format
- Choose Parasoft > Show View > Suppressions (deprecated) from the main menu to open the deprecated Suppressions view.
- Choose Migrate suppressions... from the menu.
- Confirm the migration when prompted.
One of the following scenarios will be applied.
Connected to Team Server
If connected to Team Server, SOAtest checks for team suppressions stored on Team Server and not the local workspace.
- Deprecated team suppressions detected by SOAtest will be converted to plain text and saved in the parasoft.suppress file(s) located in the same location as the corresponding source file(s).
- Deprecated team suppressions will continue to be available on Team Server.
- Deprecated team suppression will remain in the Suppressions (deprecated) view until removed manually (see Removing Suppressions).
Suppressions stored on Team Server that point to remote URLs (such as Suppressions containing URLs will only be created for static analysis results obtained by running a Scanning Tool or a browser test scenario (see Web Tools). You will need to migrate the suppressions manually by adding them to the parasoft.suppress file.) will not be migrated.
If not connected to Team Server, SOAtest checks for suppressions stored in the local workspace and not Team Server.
- Deprecated local suppressions detected by SOAtest will be converted to plain text and saved in the parasoft.suppress file(s) located in the same location as the corresponding source file(s).
- A backup file that contains local suppressions in the deprecated format is created. The location of the file is printed to the console.
- Deprecated local suppressions are removed from the workspace and from the deprecated Suppressions view.
Restoring Deprecated Local Suppressions from Backup File
- Close your IDE.
Go to the location where the backup file is stored (the location is printed to the console). It contains a local_suppressions_backup.zip file.
Extract the contents of local_suppressions_backup.zip to the same location.
You can re-migrate restored local suppressions on next IDE startup.
Enabling Team Server Suppressions (Deprecated)
The Suppressions view associated with viewing XML-style suppressions is deprecated, but you can enable Team Server suppressions and view suppressions that were created with an older version of SOAtest from the Suppressions (deprecated) view:
- Choose Parasoft > Show View > Suppressions (deprecated) from the main menu.
- Choose Enable deprecated suppressions from the ellipses menu.
You can delete suppressions from the parasoft.suppress file to un-suppress a task. Re-run the test or analysis and the task will reappear in the Quality Tasks view.
If suppressions are stored on Team Server, choose a suppression and click the delete (X) button in the Suppressions (Deprecated) view.