Using Test Lists
You can create test lists to organize tests into groups. Test lists persist between sessions. You can import test lists that were created in one solution into another solution.
Using Test Lists
You create test lists by using the Test List Editor. For more information, see How to: Create a Test List. After you have created test lists, you can use them in the following ways:
Run multiple tests. Using the Test List Editor, you can select one or more test lists and run them. Results for all the contained, enabled tests are produced as if you had run the tests individually. For more information, see How to: Run Automated Tests from Microsoft Visual Studio.
You can also run test lists from the command line, using the MSTest utility with its /testlist: option. For more information, see How to: Run Automated Tests from the Command Line Using MSTest and MSTest.exe Command-Line Options.
Run tests as part of a build. When your development project is part of a team project of Team Foundation Server, the build process can run tests in test lists to verify the functionality of each just-completed product build. For more information, see Create a Basic Build Definition and How to: Configure and Run Scheduled Tests After Building Your Application.
Enforce check-in policy. Test lists are used as a part of check-in policy. Check-in enforces that all tests in the selected test lists be run successfully before the corresponding source code is checked in. For more information, see Add Check-In Policies.
Display of Tests and Test Lists
The test lists pane of the Test List Editor always displays the following three top-level nodes:
Lists of Tests. This is the root node of the test list hierarchy and, initially, it is empty. The Lists of Tests node can contains multiple test lists. Every test list, at any level in the hierarchy, can contain multiple tests and test lists. A test can exist in more than one test list; for more information, see How to: Organize Tests into Test Lists. To run the tests in a test list, select the check box for the test list, and then click Run Tests.
Note
If you run the tests that belong to one test list, but see that other tests are being run, it could be because other tests in other lists, or in the All Loaded Tests node, have been selected, even though they are not currently displayed. An example of this is when you run a test list that contains other test lists. The tests in the child test lists will also run, even if the child lists are not visible because the parent list is collapsed. Additionally, some test types, namely ordered and load tests, can contain other tests. When you run the containing test, the contained tests will also run.
Tests Not in a List. This is a non-hierarchical list of all the tests in your solution that have not been moved into one or more test lists.
All Loaded Tests. This is a non-hierarchical list of all the tests in your solution. It displays all instances of all tests. If a test exists in two test lists, it is displayed twice in the All Loaded Tests node.
States of Test Lists
A test list can be in any one of the following four states:
Unchecked. None of the available tests in this list, nor in any of its child lists, are currently checked.
Checked. All the available tests in this list, and all its child lists, are currently checked.
Indeterminate. This is indicated by a dimmed check mark. Some of the available tests in this list, in its child lists, or both are selected.
Disabled. The list is unavailable. This test list and its child lists contain no tests that are available to be checked.
A test is available to be checked if it is enabled and it is not filtered out.
Example: If you have a test list that contains three tests, and you check two of them, the check-mark for that test list will become dimmed, which indicates the indeterminate state. If you then disable the unchecked test, the test list's check box becomes checked because all available tests are checked. If you then re-enable that test, the test list becomes indeterminate again. If you disable all three tests, the test lists check box becomes disabled, because there are no tests in this test list that can be selected.
Storage and Reuse of Test Lists
Test lists reside in test metadata files, which in turn reside in the Solution Items folder of a solution. As you add, delete, or change test lists, or add tests to test lists or remove tests from them, their descriptions are updated in the metadata file. The metadata file is an XML file.
See Also
Tasks
How to: Run Automated Tests from Microsoft Visual Studio
How to: Run Automated Tests from the Command Line Using MSTest
How to: Configure and Run Scheduled Tests After Building Your Application
Create a Basic Build Definition
How to: Disable and Enable Tests