Certain errors can be encountered for any test that can run automatically, which means any test type other than manual. These errors are frequently related to the deployment of tests. When a test is deployed, the file that contains it is copied to another folder, either to a location on the local computer or to a remote computer. For more information, see Test Deployment.

For unit tests, for example, the .dll file that was built from the test project is the file that must be deployed. If this binary file cannot be deployed, any unit tests that it contains are immediately marked as Failed in the Test Results window when you run them.

To fix this error, verify that the files are available on your local computer and that there were no build errors the last time that you rebuilt your test binaries.

Not only binary files can be deployed. You might specify that a particular file, such as a data file, is required by a test and must therefore be deployed with the test. At deployment time, if this file cannot be found because it has been moved or deleted, the test cannot run correctly and an error occurs. Also see Details by Test Type for information about this error with regard to generic tests.

To investigate this error, first note the files and folders specified on the Deployment page of the dialog box used to edit test run configurations. For more information, see How to: Specify a Test Run Configuration. Then check those files and folders on disk to make sure they are present and that their names are identical.

Your solution may have multiple run configuration files. If this is the case, make sure that you examine the run configuration that was active when the test error occurred. To determine which run configuration was active, examine the Test Run Details page for that test run. For more information, see the section "Test Run Details Page" in Test Results Reported.

For more information about active run configuration files, see How to: Apply a Test Run Configuration.  

When you run tests remotely, the test results might not display. This error is probably related to the remote nature of the test run.

Like test results from local test runs, results from remote runs are reported to you locally. The reporting of certain remote test results depends on the ability of Visual Studio Team System Test Edition to copy generated test results files from the remote test computer to your local computer.

If you find errors that occur with remote test results, start by determining whether the network connection between the remote computer and the computer on which you are running Visual Studio has been interrupted.

For more information, see Troubleshooting Controllers, Agents, and Rigs.

To enable the reporting of code-coverage, the binary files that are tested must be instrumented and then deployed before tests are run on them.

A failure to instrument the binary file causes the reporting of code coverage to fail. After the test run is completed, the Test Run Details page displays an error message stating that code coverage could not be reported, and it also states the cause.

Possible causes for a failure to instrument a binary file in place are that it is marked as read-only or it is being used by another process. To fix the error of a read-only binary file, first examine the attributes of the binary file to make sure that it can be written to. To know which binary files to check, open the Code Coverage page of the active run configuration; it is here that you specified files for instrumentation. For more information, see How to: Obtain Code Coverage Data.

Another cause for failure of code coverage when using in-place instrumentation can occur when you are using one or more unit tests together with a manual test. During the manual test, the tester runs the production code that is being tested. If the tester presses F5 or CTRL+F5 to start or debug the code, the project's executable file is rebuilt, which removes the instrumentation.

Also, make sure no other process is using the binary file. For example, make sure that you do not have the file open in another instance of Visual Studio.

When instrumenting a Strong-Named Assemblies, you can encounter other errors that are related to re-signing the assembly. For more information, see Instrumenting and Re-Signing Assemblies.

To improve the performance of Visual Studio, close old test results.

When you run tests, Visual Studio stores the test runs and test results in memory. As more test runs and results accumulate, more memory is allocated. You can release test runs from memory by clicking Close Results on the Test Results window toolbar. This action releases test results objects but does not explicitly call the garbage collector. This means that the memory will become available, but not necessarily immediately.

You can also set the maximum number of test runs to keep in memory. For more information, see How to: Limit the Number of Stored Test Runs.

You can obtain code coverage data only when you test code in 32-bit assemblies. To guarantee this condition, set a particular build property:

• For C# projects, set the Platform target to x86. For more information, see How to: Set Build Properties (C#).

• For Visual Basic projects, set Target CPU to x86. For more information, see Advanced Compiler Settings Dialog Box (Visual Basic).

Note:
This warning does not apply to C++ projects because AnyCPU is not a platform choice for C++ projects.

If you build your project with the value of AnyCPU, tests that are run on the resulting assembly produce code coverage data, but the test run also generates a warning. You can see the text of the warning on the Test Run Details Page:

Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process.  The CLR header flags have been updated to reflect this.

This warning means that the assembly has been recompiled with the x86 property applied for the purpose of obtaining code coverage data during this test run. To avoid this warning, compile any assembly for which you want code coverage data with the x86 setting.

Note:
If your application is meant to run on both 32-bit and 64-bit computers, remember to recompile it using the AnyCPU setting after testing has completed.

You might encounter a situation in which the test execution engine opens and locks an assembly in your test project. When this happens, you cannot, for example, save changes to the assembly. This problem might occur in the following situations:

• Case 1: You have disabled deployment for your test project, TestProjectA. TestProjectA was compiled in C++/CLI. The code within TestProjectA defines an attribute class, and that attribute decorates at least one of the test methods in TestProjectA. At this point, when you run unit tests in TestProjectA, the test execution engine opens TestProjectA.DLL and can leave it in a locked state.

• Case 2: Your test project, TestProject1, contains a DLL that was compiled from a second test project, TestProject2. TestProject2 was compiled in C++/CLI. The code within TestProject2 defines an attribute class, and that attribute decorates at least one of the test methods in TestProject2. Now, when you run unit tests in TestProject1, the test execution engine opens TestProject2.DLL and can leave it in a locked state.

In both of these cases, the solution might have two parts. First, perform the following steps.

1. On the Tools menu, select Options.

   The Options dialog box opens.

2. Expand Test Tools and click Test Execution.

3. Under Performance, clear the check box for Keep test execution engine running between test runs.

After you complete these steps, if the problem persists, do the following:

Change your code so that the test project that was compiled in C++/CLI does not need to be loaded in the default AppDomain. One way to do this is to move the definitions of the custom attributes that you use into a separate assembly that is implemented in C#.

Certain errors frequently occur or primarily while you are running particular test types, as described in this section.

• Manual tests. Manual tests cannot be run remotely. When you try to start a test run that includes a manual test, Test Edition tries to remove the manual test from the test run. When this occurs, you are alerted of this fact and given the choice of canceling the test run or letting it proceed without the manual test. For more information, see Dialog Boxes of Test Edition.

• Ordered tests. Errors that are encountered with ordered tests frequently involve file deployment. Before the test engine can run an ordered test, it must locate and then deploy all the test files for all the contained tests, in addition to all other required files. Failure to do this for any of the individual tests would cause an error.

• Generic tests. Deployment errors can also occur when you run generic tests. You can specify files to be deployed in two ways for generic tests: on the Deployment page of the test run configuration, and on the authoring page of the Generic test itself. The test might fail if you neglect to list all the required files or if Team System testing tools cannot find those files at the locations you specified.

  These two different ways to deploy files cause errors to appear at different levels. If the deployment error relates to a file specified in the Generic test authoring page, the error will surface at the test level. If the deployment error relates to a file specified in run configuration, the error will surface at the run level.

Tasks

Concepts

Other Resources