Remote Coverage Analysis from Visual Studio

Setting up remote coverage

To enable remote coverage, you need to install, configure, and run the coverage server application on a remote machine and make the corresponding configurations in dotCover settings in Visual Studio.

If you are going to run remote coverage of MSTests, make sure that Visual Studio is installed on the remote machine. Local and remote Visual Studio installations must have the same version and must be installed into identical directories.

NUnit tests are natively supported by the coverage server, so you do not even need to install NUnit on the server.

To set up a coverage server

1. Do one of the following:

   • In Visual Studio, go to ReSharper | Options | dotCover | Remote Coverage and click Get Server Package. dotCover will generate an archive with all necessary files.

   • Download dotCover command line tools package from JetBrains website.

2. Copy the archive to the machine where you are going to run the remote coverage server.

3. Extract files from the archive and run dotCover.RemoteCoverageServer.exe with one of the following parameters:

   • dotCover.RemoteCoverageServer run - to start coverage server as a console application process with default settings.

   • dotCover.RemoteCoverageServer install /StartServer - to install coverage server as a service and start it with default settings. Running coverage server as a service has a number of benefits. For example, you can configure to start the service on machine startup, it does not require a user to be logged in, etc.

   • dotCover.RemoteCoverageServer help - to study available parameters of the coverage server.

   If you need to run it with some custom configuration, see configuring coverage server.

4. By default the server starts on port 9081 and is ready to execute coverage requests from dotCover.

To configure remote coverage in Visual Studio

1. Open the dotCover | Remote Coverage page of dotCover options.

2. Select the Cover unit tests remotely check box.

3. Specify IP address or host name and the port of the coverage server in the corresponding fields.

4. Click Test connection. If the server is configured properly, you will see the confirmation message. Otherwise, study the error message and correct the settings or restart the server.

5. If the covered tests use external test data, specify directories with test data files. Click Add Folder for each new directory.

6. Click Save to apply the modifications and let dotCover choose where to save them, or save the modifications to a specific settings layer using the Save To drop-down list. For more information, see managing and sharing dotcover settings.

If you need to get back to running coverage analysis locally, clear the Cover unit tests remotely check box on the dotCover | Remote Coverage page of dotCover options.

Running coverage analysis on a remote server

If dotCover is configured to run coverage analysis remotely, a green cloud icon in the right bottom corner of the Visual Studio window notifies you about it:

This cloud icon turns red if there are problems with the server connection.

Each time you run coverage analysis of unit tests from Visual Studio, all coverage analysis are done on the server side. As soon as the analysis is finished, the results appear in the Unit Test Sessions window automatically.

Optional configurations of coverage server

You can specify parameters of the coverage server in the command line arguments or in the configuration file dotCover.RemoteCoverageServer.exe.config. If some preference is specified in both ways, command line arguments take preference.

If you run coverage server as a Windows service,

There are the following configurable parameters:

• PortNumber - an optional parameters that allows you to specify a custom port number. By default, the port number is 9081.

• PathToFileStorages - an optional parameter that allows you to specify a different directory for clients' files. By default, these files are stored next to the remote server application.

• WorkspaceHostsPoolSize - this optional parameter lets you specify how many separate processes should be reserved for clients' snapshots. As soon as a new client connects to the server, its calculations are started in a free process and one new processes is added to the reserve pool.

• WorkspaceHostInitializationTimeout - this optional parameter lets set the time limit (in milliseconds) for initialization a new client process.

• AllowedFileStorageInactivityPeriod - this optional parameter lets set the time limit (in hours) to keep the files of a client that has disconnected from the server

• To enable logging, use the LogFile parameter. If there is no path argument, the logs are saved in %Temp%JetLogs folder with auto-generated name.

• LogLevel - optionally sets the logging level with one of the following values: INFO, VERBOSE, TRACE.