A unit test is a programmatic test that is either coded in Visual C# or Visual Basic, or that is coded in Visual C++ and compiled with /clr:safe, and that exercises a project's methods.

Note:
For details on how to use unit tests with C++ production code and how to use unit tests written in C++, see Unit Tests and C++.

A unit test calls the methods of a class, passing parameters, and verifies that the returned value is what you expect. You can write unit tests by hand or generate them automatically.

The Add New Test dialog box provides two ways to create unit tests:

• Use Unit Test to add to your test project a source file that contains a valid but empty unit test method that you can then code by hand.

• Use Unit Test Wizard to display the Create Unit Tests dialog box, which you use to generate unit tests from methods in your current project. You can also display the Create Unit Tests dialog box by right-clicking your source code and clicking Create Unit Tests. After you generate unit tests, you still must edit them by hand to prepare them for use.

There are specialized variants of unit tests:

• Data-driven unit tests are created when you configure a unit test to be called repeatedly for each row of a data source. The data from each row is used by the unit test as input data. For more information, see Overview of Data-Driven Unit Tests.

• ASP.NET unit tests are unit tests that exercise code in an ASP.NET Web application, and are run either in the ASP.NET Development Server or in the IIS process. For more information, see Unit Tests for ASP.NET Web Services.

• Smart Device Unit Tests. Visual Studio provides a suite of tools for testing C# and Visual Basic smart device applications. As with ASP.NET unit tests, the unit tests that you use to test smart device applications also run in a custom host adapter. For more information, see Testing Tools for Smart Device Projects.

For more information, see Working with Unit Tests. For a step-by-step example, see Walkthrough: Creating and Running Unit Tests.

A generic test is an existing program or test from another source that has been wrapped to function as a test in Visual Studio.

A generic test typically wraps an automated test or tool that was previously created outside the Visual Studio Team System framework. Using generic tests, therefore, is a means for taking advantage of existing test infrastructure.

The following are examples of tests or programs that you can use in generic tests:

• An existing test that uses process exit codes to communicate whether the test passed or failed. 0 indicates passing and any other value indicates a failure.

• A general program to obtain specific functionality during a test scenario.

• A test or program that uses an XML file to communicate detailed results. The XML file must conform to the Visual Studio generic test results schema. This schema is defined in the file [drive:]:\Program Files\Microsoft Visual Studio 9\Common7\IDE\PrivateAssemblies\SummaryResult.xsd.

For more information, see Working with Generic Tests. For a step-by-step example, see Walkthrough: Creating and Running a Generic Test.

You use a load test to encapsulate non-manual tests, that is, unit, Web, generic, ordered tests, and then run them simultaneously by using virtual users. Running these tests under load generates test results, including performance and other counters, in tables and in graphs.

For example, by adding a Web test to a load test, you can simulate the simultaneous interaction of hundreds of users who are accessing the Web application. This lets you test the behavior of the Web application under peak use before you deploy it, in order to find application errors or bottlenecks.

For more information, see Working with Load Tests. For a step-by-step example, see Walkthrough: Creating and Running a Load Test.

Manual tests are used for stepping through tasks, typically for tests that are difficult or impossible to automate, such as a test in which the connection between the computer and its power supply is interrupted. Use this test type when you need the test tasks to be completed by a test engineer, not by an automated script.

You can create a manual test in either of two formats:

• Text Format. The text format is edited by using a simple text editor that does not provide rich formatting capabilities.

• Word Format. The Word format is edited using Microsoft Word and allows for richer content, including text formatting and embedded graphics.

When you create a manual test, you describe the steps that you want the tester to follow. For more information, see Working with Manual Tests. For a step-by-step example, see Walkthrough: Creating and Running a Manual Test.

An ordered test is a container that holds other tests, that is, unit, Web, generic, manual, and ordered tests, but not load tests. An ordered test guarantees a specific execution order. For more information, see Working with Ordered Tests.

Web tests consist of an ordered series of HTTP Requests that you record in a browser session using Microsoft Internet Explorer. You can also create a coded Web test, in which you can add more advanced features, such as flow control. You can have the test report specific details about the pages or sites it requests, such as whether a particular page contains a specified string.

After you record a Web test, you can edit it to assign properties such as think times and a data source that stores data to post to the Web server. Web tests become more powerful when they are used as part of a load test.

For more information, see Working with Web Tests. For a step-by-step example, see Walkthrough: Recording and Running a Web Test.

Other Resources