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. If 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.

You can also include or exclude files that are connected to shared projects. For example, by using the -exclude option and providing path to a file within a shared project, it will exclude it from all implementation projects:

-exclude "C:\Devel\FooSolution\SharedProject\*.*"

To modify the scope within a single implementation project of files from a shared project, the pattern should look like this:

-exclude "C:\Devel\FooSolution\ImplementationProject\SharedProject\*.*"

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

Connection to a supported source control system must be properly configured (see Connecting to Source Control and Source Control Settings).
The scope.scontrol=true setting must be configured to enable computing authorship based on your source control system (see Scope and Authorship Settings).

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.