Getting Started with Team System Testing Tools
This section takes you on a tour through the tools and windows of Microsoft Visual Studio Team System Test Edition. You will see basic aspects of the Team System testing tools, such as how to create and work with tests, the types of tests that are available, and how to configure the testing tools.
Not all of the functionality described here is available in Visual Studio Professional Edition. In this walkthrough, you cannot perform the following steps if you are using Visual Studio Professional Edition: Create a manual test; publish test results; use the Test List Editor; create, run, and re-use test lists. For complete information about the testing capabilities that Professional Edition offers, see Using Testing Tools in Visual Studio Professional Edition.
Not only testers can benefit from the Team System testing tools. Programmers, especially those who create tests, will use many of the features of the Team System testing tools. Both roles are described here:
Tester. After you start Visual Studio with the tester profile, certain menus and windows that are specific to programming are removed, which lets you focus on the tasks of creating non-programmatic tests, managing existing tests, and running tests. For more information, see Creating and Editing Tests, Managing Tests, and Running Tests.
Programmer. When you start Visual Studio, you can select whichever language you think you will be most likely to use, or to learn, as you program production code or code used for testing purposes. Choosing a language on the Choose Default Environment Settings dialog box identifies you as a programmer. No menus and windows are hidden when you make this choice. For more information, see Creating and Editing Tests and Running Tests.
Here is a quick overview of features that are specific to the Team System testing tools.
A tour through the features of Team Edition for Testers
Start Visual Studio.
Click the Test menu.
Through this menu, you can create new tests, make settings for your test environment, configure remote test runs, and open the windows of the Team System testing tools. Several default test types are offered; for more information, see Selecting a Test Type.
As you created the new test, a solution was created and a test project was automatically added to the solution. A test project can contain any number of tests of any type. Test projects exist alongside the other projects of your solution. They are built into assemblies just like other kinds of projects.
In Solution Explorer, double-click the file with the extension .testrunconfig.
This displays the run configuration dialog box. By editing your run configuration, you can change many aspects of the way your tests run. You can store multiple sets of run configuration settings, but only one set is active. Your tests are run according to whichever run configuration is currently active. For more information, see Configuring Test Execution.
Click Test, click Windows, and then click Test View.
The Test View window displays all the tests that are currently loaded. You use it during the process of test development. For more information, see Viewing and Running Tests.
Now, run your Web test. See How to: Run a Web Test.
Running a test opens the Test Results window. This window displays a summary of test results, in tabular form. It displays one test run at a time; within the test run, each row represents the result of one individual test.
You can double-click a row in the Test Results window to obtain more detail about the results of that test. By clicking Show Code Coverage Results on the Test Results window toolbar, you can also see data on the extent to which your code was covered when tests were run against it. For more information, see How to: Obtain Code Coverage Data.
If your are connected to Team Foundation Server, you can also publish your test results data, create work items from tests or test results, and associate tests or test results with existing work items; see Integration with Team System.
Click Test, and then click Windows, and then click Test List Editor.
This displays the Test List Editor. If you are a tester, you will probably use the Test List Editor frequently. You can use it to organize tests into lists, to run tests, to filter and group the display of the tests you have loaded, to import additional tests into your currently loaded set, and to export tests. If you have no tests currently loaded, you can use the Test List Editor to load tests from folders on the hard drive. For more information, see Managing Tests.
Open a Visual Studio 2005 command prompt and type mstest /?.
This is the MSTest.exe command line test utility. You will probably use this command if you are running tests in a test or build lab. This command lets you run tests and obtain results, and to publish your test result data so that the rest of your team can use it. For more information, see Command-Line Test Execution.
Create a manual test. For more information, see How to: Create a Manual Test.
In the Test List Editor, right-click Lists of Tests, and then click New Test List.
Type a name of your choosing and then click OK.
You have created a test list. Test lists are containers into which you organize tests.
In the Test List Editor, click All Loaded Tests.
Drag your Web test and your manual test into the test list that you just created.
You have just populated the new test list with your two tests.
Click the box next to your test list and click the Run Checked tests button.
This runs all the tests in the test list. One of those tests is a manual test. When you run a manual test, Visual Studio displays a dialog box to alert you of that fact. This is an example of one of several cases in which a dialog box asks you how to proceed or alerts you to a certain situation. As with most facets of Visual Studio, you can customize the behavior of dialog boxes such as this by making settings on a page reached through the Options option of the Tools menu. For more information, see Dialog Boxes of Test Edition.
If your Visual Studio session is connected to a Team Foundation Server, you can use the team-related aspects of Team System testing tools, such as the following:
You can publish test results and code-coverage data to the Team Foundation Server. For more information, see Publishing Test Results. After test results are published, they can be viewed and analyzed by the rest of your team.
You can create a bug from a test result. For more info, see How to: Create a Work Item from a Test Result.
You can download published test results from a build. For more information, see How to: View Test Results Through a Build Report.
After you have created a test list, you can reuse it when a person working in the build lab using Team Foundation Build creates a build type, such as for the process of running build verification tests. For more information, see How to: Create a Build Definition and How to: Configure and Run Build Verification Tests (BVTs).
A test list can be associated with a check-in policy. For more information, see Working with Check-In Policies and Notes. This means that a project manager can specify that, before particular code is checked in, it must be tested using a specific set of tests.