Here are the situations in which a dialog box prompts you to clarify or confirm an action:

• When a manual test result window is to be opened for execution. You have started a test run that contains one or more manual tests. As each manual test is encountered, a dialog box alerts you that the test is about to open for execution.

• When a new deployment item is not in the solution folder. When you edit test run configuration settings, you can choose new files or folders to be deployed when tests are run. If you choose a deployment item that is not in the solution folder, a dialog box alerts you to this fact and warns that the item might not deploy correctly if the run configuration is used on a different computer. You are prompted to confirm your addition of the deployment item. For more information about how to set run configurations, see How to: Specify a Test Run Configuration.

• When a remote test run contains manual tests. When you try to run a selection of tests remotely, manual tests are automatically removed from the test run. You can choose whether to be notified of the removal. For more information, see Removing Manual Tests from Remote Test Runs.

• When adding InternalsVisibleTo attribute. Your code contains elements that have the internal access qualifier. When you generate unit tests, a dialog box appears that asks whether to add the InternalsVisibleTo attribute. You can choose whether to apply a single answer to this question in the future, which also suppresses the dialog box. For more information, see Unit Tests for Private, Internal, and Friend Methods.

• When adding metadata files to solution items. You are trying to add a test metadata file to a solution that already contains a test metadata file. You are prompted whether you want to replace the existing metadata file, or merge the two metadata files together. For more information, see Adding Metadata Files to Solution Items.

• When an empty test run is about to be aborted. After a manual test is removed from a remote test run, that test run might be empty. The Team System testing tools will not run an empty test run, and you can choose whether to have it notify you of this situation. For more information, see Stopping an Empty Test Run.

• When canceling the publishing of a test run to the Team Foundation Server. If you start to publish test results and then cancel the publication, this dialog box appears. The dialog box just requests confirmation that you want to cancel publication.

• When changing a property of a manual test in the Properties window while the manual test is open in Microsoft Word. While you have a manual test in Microsoft Word format open, you can edit its properties in the Properties window of Visual Studio. After you edit a property, Visual Studio displays a dialog box that alerts you that the property will be saved to the Word file. Clicking OK saves the changed property; clicking Cancel does not save the changed property.

• When closing a running manual test.You are running a manual test, but before you finish it, you close the test. A dialog box appears to warn you that closing the manual test window will abort the manual test. Answering OK aborts the test.

• When creating a work item from an unpublished test result. You are creating a work item from a test result that you have not yet published to the operational store. A dialog box appears that prompts you whether to first publish the test result before creating the work item.

• When deleting a published test run from the Team Foundation Server. If you choose to delete a published test run, this dialog box appears. The dialog box requests confirmation that you want to delete the published test run.

• When deleting one test run or multiple test runs. Using the Test Runs window, you select test runs and then press or click Delete. A dialog box requests confirmation that you want to delete the test run or test runs. For more information, see Deleting a Test Run.

• When excluding a test from a group. You change the properties of a test so that it is no longer displayed in a particular group in the Test List Editor or the Test View window. You can choose whether to be required to confirm this action. For more information, see Excluding a Test From a Group.

• When importing test lists, if there is a test list ID conflict. You are importing a test metadata file that contains test lists. The unique identifier of one of these test lists matches the identifier of a test list already in your solution. This causes a conflict that you are prompted to resolve. For more information, see Importing Test Lists.

• When loading a legacy file. The format of XML documents used by tests in Visual Studio changed between Visual Studio 2005 and Visual Studio 2008. If you use Visual Studio 2008 to open a solution that contains outdated files, Visual Studio displays the Visual Studio Conversion Wizard. This wizard gives you the option of creating a backup of the files before converting them. When you click Finish, Visual Studio converts the files and opens the solution.

• When loading a metadata file, if a test link cannot be found. You are loading a test metadata file that contains test lists, which in turn contain links to tests. One of the links to a test cannot resolve; that is, the test cannot be found at the stated path. You are prompted to decide what to do next. For more information, see Loading a Metadata File: Links Missing.

• When loading tests or test run configurations, if there is an ID conflict. You are loading a solution that contains tests or test run configurations. The unique identifier of one of these entities matches the identifier of a test or test run configuration already in your solution. This causes a conflict that you are prompted to resolve. For more information, see Loading Tests or Test Run Configurations.

• When opening manual tests in Word format when Microsoft Office Word 2003 (or later versions) is not installed. Your solution might contain a manual test in Word format that you authored in the past, or that someone else authored and gave to you. If you open that test while Word is not installed, Visual Studio opens the test in read-only mode in the main editing window. The dialog box alerts you to the fact that the test opens in read-only mode.

• When starting a remote test run or a run with code coverage under the debugger. When you are running tests on a remote computer, you cannot gather code coverage information nor can you run tests under the debugger. If you start a test run that tries either of these actions, a dialog box informs you that the test run will continue to run, but locally, not remotely.

• When submitting a test run that contains manual tests. When you start a test run that contains at least one manual test, a dialog box alerts you about the manual test.

• When using a test run configuration file on a computer where Visual Studio Team System Test Edition is not installed, and a remote computer for running tests is specified. 

  A user of Visual Studio Team System Test Edition can create and save a test run configuration that specifies remote execution of tests. You might be running Visual Studio Professional Edition or Visual Studio Team Edition for Developers, which cannot be used to run tests remotely. If you use this test run configuration file in Visual Studio Professional Edition or Team Edition for Developers, a dialog box prompts you whether to run tests locally.

• When importing test run configurations, if there is a test run configuration conflict. You are trying to import a test run configuration. Its identifier matches that of a test run configuration already in the Solution Items folder. This causes a conflict that you are prompted to resolve. For more information, see Importing Test Run Configurations.

The following sections describe many of these situations in more detail, to help you decide what to do when you experience them.

As described in Reusing Tests, test lists have unique identifiers. When the identifier of a test list you are importing conflicts with the identifier of a test list in your solution, a dialog box prompts you with the following options:

• Always abort importing that metadata file. This choice cancels the entire import operation. The result will be as if the operation was never started. None of the imported test lists will be present, regardless of the point in the operation at which the conflict occurred.

• Always replace the existing test list with the new one. The conflicting test list is imported and it replaces the original test list that has the same identifier. The importing of test lists continues until the end of the metadata file, or the next conflict, is reached.

• Always keep the existing test list. The conflicting test list is not imported, but the import action continues until the end of the metadata file, or the next conflict, is reached.

• Always merge the test lists. Even if two test lists conflict, merge the tests they contain into one resulting test list. The merged test lists will contain the tests from both original test lists.

You can use this dialog box not only to answer the question you have been prompted for. You can also set the answer that you select to be the default, by clicking Do not show this dialog box again, before you click OK. You can also change your default answer. For more information, see How to: Configure the Dialog Boxes of Test Edition.

You are loading a solution that contains tests or test run configurations. At least one test or test run configuration has an identifier that conflicts with a test or test run configuration already present in your solution. This causes a conflict that you are prompted, with a dialog box, to resolve. This dialog box presents you with the following options:

• Always abort loading that file. None of the tests and run configurations contained in that file will be loaded. For example, if the specified file contains three tests, and one of them conflicts and then you select abort, none of those three tests will be loaded.

• Always replace the existing entry with the new entry. The conflicting test or run configuration file will be loaded, and loading will continue. The result is that the entry that is currently being loaded will be kept; the entry that had been loaded previously will be discarded.

• Always keep the existing entry. The conflicting test or run configuration file will not be loaded, but loading will continue with the next item. The result is that the file that was previously loaded will be kept, and the current file will be discarded.

In addition to making this choice, you can also set the answer that you select to be the default. Set the default by clicking Do not show this dialog box again, before you click OK. You can also change your default answer. For more information, see How to: Configure the Dialog Boxes of Test Edition.

Manual tests can be run locally, but not remotely. Therefore, when Team System testing tools detects that a test run you are initiating contains one or more manual tests, it removes the manual tests from the test run. It does not delete the manual tests from your test project.

When Team System testing tools deletes a manual test from a remote test run, it uses a dialog box to warn you. You can also use this dialog box to have Team System testing tools stop alerting you. To do this, click Do not show this dialog box again, before you click OK. For more information, see How to: Configure the Dialog Boxes of Test Edition.

Like tests and test lists, test run configurations are identified by a unique identifier. When the identifier of a test run configuration that you are importing conflicts with the identifier of a test run configuration in your solution, a dialog box prompts you with the following options:

• Always keep the imported test run configuration. The test run configuration that you are importing replaces the original one that has the same identifier.

• Retain the current test run configuration. The test run configuration is not imported. Instead, your solution will use the test run configuration already present in the Solution Items folder of your solution.

In addition to making this choice, you can also set the answer that you select to be the default, by clicking Do not show this dialog box again, before you click OK. You can also change your default answer. For more information, see How to: Configure the Dialog Boxes of Test Edition.

After you have run tests, test run results are displayed in the Test Results window. You can delete one or more test runs by right-clicking them and then clicking Delete Test Run.

By default, Team System testing tools displays a dialog box that prompts you to confirm deletion of the test run. You can also use this dialog box to have Team System testing tools stop asking for this confirmation. To do this, click Do not show this dialog box again, before you click OK. For more information, see How to: Configure the Dialog Boxes of Test Edition.

As explained in the section Removing Manual Tests from Remote Test Runs, Team System testing tools automatically removes manual tests from remote test runs. If the test run contained only manual tests, it then becomes an empty test run. Team System testing tools will not execute an empty test run.

When Team System testing tools stops an empty test run from running, it uses a dialog box to warn you. You can also use this dialog box to have Team System testing tools stop alerting you. To do this, click Do not show this dialog box again, before you click OK. For more information, see How to: Configure the Dialog Boxes of Test Edition.

As described in Reusing Tests, you can add metadata files into the Solution Items folder of your solution in various ways, including the following:

• Right-click the Solution Items folder and select Add Existing Item.

• Drag a metadata file to the Solution Items folder.

You are trying to add a test metadata file to a solution that already contains a test metadata file. Team System testing tools uses a dialog box to ask whether you want to replace the existing metadata file, or merge the two metadata files together. By using this dialog box, you can also set your answer to be the default that is used when this situation is encountered in the future. To set the default, click Do not show this dialog box again, before you click OK. For more information, see How to: Configure the Dialog Boxes of Test Edition.

You can load a test metadata file by clicking Load Metadata File on the Test List Editor toolbar, and then selecting the metadata file from the directory structure of the other solution. When you do this, Team System testing tools tries to resolve the references to all the tests that are described in the metadata file.

When a reference to a test cannot be resolved, a dialog box is displayed that asks you how to proceed: whether to stop loading the metadata file completely; to ask you to locate the test that was not found; or to skip that one file only.

You can set your answer to be the default that is used when this situation is encountered in the future. To do this, click Do not show this dialog box again, before you click OK. For more information, see How to: Configure the Dialog Boxes of Test Edition.

Using the Test List Editor or the Test View window, you can group tests by property, for example, by the test's owner. Similarly, you can remove a test from a group. To do this, right-click the test in the Test List Editor and select Exclude from Group. This action has two effects: It removes the test from the group, and it clears the value of the property by which the test was grouped. For example, if you Exclude from Group a test whose Owner property was set to 'Joe', the value 'Joe' is removed from the Owner property, leaving the property empty.

After you select Exclude from Group, a dialog box is displayed that prompts you to confirm this action. You can also use this dialog box to stop prompting you to confirm the test-exclusion action. To do this, click Do not show this dialog box again, before you click OK. For more information, see How to: Configure the Dialog Boxes of Test Edition.

When you generate unit tests for code elements that have the internal access qualifier, the Add InternalsVisibleTo Attribute dialog box appears. It asks whether to add the InternalsVisibleTo attribute to your project. If you answer yes, the assembly of your code under test is marked with the InternalsVisibleTo attribute, which makes the internal types in that assembly visible to your test project. This lets you perform unit tests on those internal types. For more information, see Unit Tests for Private, Internal, and Friend Methods.

In the Options dialog box that is reached through the Tools menu, you can choose to apply a single answer to this question in the future, which also suppresses the dialog box. To do this, select one of the following choices:

• Always try to add InternalsVisibleTo attribute. If you choose this option, Visual Studio tries to add the InternalsVisibleTo attribute to the project of your code under test, which makes elements marked internal visible to your test project.

• Never try to add InternalsVisibleTo attribute. If you choose this option, Visual Studio does not try to add the InternalsVisibleTo attribute. In this case, internal types are treated as if they were marked private, which causes test generation to create a private accessor to test your assembly.

Tasks

Concepts