In this section:

Configuring the Primary Scope

The test scope defines the set of files to analyze with dotTEST. You can specify the primary testing scope with the -solution, -project, and -website option.  You can narrow down that scope by using the -resource, -include, and -exclude options. If you specify a solution or project as your primary scope, specify the solution or project configuration, as well as the target platform. Your command line may resemble the following:

dottestcli.exe -solution "C:\Devel\FooSolution\FooSolution.sln" -solutionConfig Debug -targetPlatform "Any CPU" -config "builtin://Critical Rules" -report "C:\Report"

-solution: Specifies the path to the solution to be analyzed (you can specify more than one solution on the same command line).

-solutionConfig: Specifies the solution configuration.

-targetPlatform: Specifies the target platform.

-config: Specifies the test configuration to execute on the specified test scope.

If you are running analysis from your IDE, a source file that is open in the active editor has higher priority than resources defined with Solution Explorer and only this file will be analyzed.

Modifying the Scope with the resource option

You can narrow down the primary scope with the -resource option to specify one of the following:

  • a path to a project in a solution
  • a path to a directory of files in a project
  • a path to a file

Paths must be relative to the solution. You can use Ant-style wildcards to specify the resource.  I you want to provide absolute paths that match the file system, see Modifying the Scope with the include and exclude Options.

Examples:

Testing a Single Project in a Solution 

dottestcli.exe -solution "C:\Devel\FooSolution\FooSolution.sln" 
-resource "FooSolution/QuxProject"
-config "builtin://Demo" -report "C:\Report"

Testing a Single Directory of Files in a Project  

dottestcli.exe -solution "C:\Devel\FooSolution\FooSolution.sln" 
-resource "FooSolution/BarProject/QuxDirectory"
-config "builtin://Demo"

Testing a Single Source File

dottestcli.exe -solution "C:\Devel\FooSolution\FooSolution.sln" 
-resource "FooSolution/BarProject/QuxDirectory/BazFile.cs"
-config "builtin://Demo"

Testing a Single Project Under a Solution Folder

dottestcli.exe -solution "C:\Devel\FooSolution\FooSolution.sln" 
-resource "FooSolution/BarSolutionFolder/QuxProject"
-config "builtin://Demo" -report "C:\Report"

Testing a Single Source File When No Solution is Provided

Use the -project option only if the solution is not provided. Because the name of the solution is unknown, the solution path should start with /:

dottestcli.exe -project "C:\Devel\FooSolution\FooProject.csproj" 
-resource "/FooProject/BarDirectory/QuxFile.cs"
-config "builtin://Demo" -report "C:\Report"

Modifying the Scope with the include and exclude Options

Use the -include and -exclude switches to apply additional filters to the scope.

  • -include instructs dotTEST to test only the files that match the file system path; all other files are skipped.
  • -exclude instructs dotTEST to test all files in the primary scope except for those that match the file system path.

You can use Ant-style wildcards to specify the resource. The following example shows how to exclude all files under directories *.Tests:

dottestcli.exe -solution "C:\Devel\FooSolution\FooSolution.sln" 
-exclude "C:\Devel\FooSolution\*.Tests\**\*.*"
-config "builtin://Demo" -report "C:\Report"

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.  

Specifying Additional Assemblies

Use the -reference switch to specify a path to additional assemblies needed to resolve dependencies of the analyzed projects.  ANT-style wildcards and relative paths to the current working directory are accepted.

Examples

-reference C:\MySolution\ExternalAssemblies\*.dll
-reference C:\MySolution\ExternalAssemblies\*.exe
-reference C:\MySolution\ExternalAssemblies\**\*.dll
-reference C:\MySolution\ExternalAssemblies\**\*.dll

Use the -reference switch if you receive an "Unable to find reference assembly" message.

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.

While modifying the default scope allows you to speed up analysis, it may impact violations reported by rules that require information about other resources included in the project. In particular, rules that analyze execution paths, calculate metrics, or check for duplicate code may be prone to reporting false positives or negatives if they have no access to files excluded from the scope.

For this reason, we recommend that you regularly perform full-scope analysis to ensure that all rule violations are detected. One example scenario is that a limited scope is analyzed when working with dotTEST on the desktop, while a full-scope analysis is performed during automated builds on a server.

Prerequisites

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.


  • No labels

Need assistance? Visit our support page