Unit Tests Overview

Unit tests are programmatic tests written in Visual C# or Visual Basic, or in Visual C++ and compiled with /clr:safe.

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++.

Unit tests are used to exercise other source code by directly calling the methods of a class, passing appropriate parameters. Then, if you include Assert statements, they can test the values that are produced against expected values. Unit test methods reside in test classes, which are stored in source code files.

You can create unit tests by using a code generation feature that creates the initial source code of the test, or you can write the test completely by hand. Either way, the test class and all test methods are identified by using programmatic attributes.

Each test class is marked with the [TestClass()] attribute. Each unit test is a test method that is marked with the [TestMethod()] attribute. These attributes are assigned automatically when unit tests are generated; when you code unit tests by hand, you have to add class and method attributes yourself. For more information, see Anatomy of a Unit Test.

Generating Unit Tests

You can generate unit tests by using a dialog box reached through Visual Studio tools windows. Each unit test is created as a C#, Visual Basic, or Visual C++ method. Its code and attributes reside in a source file in a test project of the same language. The new test targets the specific code you want tested. You can generate a single unit test for an individual method, multiple tests for methods that you select, or multiple tests for all the methods in a class or namespace.

You can generate unit tests from source code in your current project. You can also generate unit tests from an assembly in the file system, which is useful when source code is not available.

The code of a newly generated test compiles, but before it can provide useful test results, you must edit it. For example, you might edit it to make variable assignments and to customize Assert statements. Generated unit tests contains TODO statements that indicate which lines of code must be edited.

Note

The Team System testing tools use naming conventions when it generates unit tests. For example, a test file is named by concatenating the word "Test" with the name of the file that contains the code you are testing; for example, "Class1Test.cs." Names of test classes and test methods are generated by using defaults also. You can change these defaults in the Test Generation Configuration dialog box, which you can open by clicking Configure on the Unit Test Generation dialog box.

For more information, see How to: Create and Run a Unit Test.

Authoring Unit Tests

You can also author a unit test by hand, without using the generation feature. The best way to do this is to add a unit test to a test project; this creates a stubbed test method that contains no code, but has the [TestMethod()] attribute applied. To complete the test, you must then edit the test in its source file, which in turn resides in a test project in your solution. For more information, see How to: Author a Unit Test and Anatomy of a Unit Test.

The Unit Testing Framework

The Unit Testing Framework provides many additional Assert classes and other classes that give you flexibility in writing unit tests. For more information, see the documentation on the namespace and types of the Unit Testing Framework under Microsoft.VisualStudio.TestTools.UnitTesting.

Test Class Inheritance

A test class is any class that is marked with the TestClass attribute. Test classes can now inherit members from other test classes. This means that you can create reusable tests in base test classes; derived test classes can inherit tests from base test classes. This feature eliminates duplicated test code and gives developers more flexibility while unit-testing production code.

A test class cannot inherit from a class that is in a different assembly. You can circumvent this limitation in the following way:

  1. Define your base test class in a source code file and add the file to Project A.

  2. Add the same source code file to a different project, Project B. To do this, right-click the project in Solution Explorer, click Add, click Existing Item, and then use the Add Existing Item dialog box to select the file.

  3. Although Project B builds into a different assembly, it includes the base test class. Other test classes in Project B can inherit from that base test class.

Inheritance Example

Your production code has two implementations: one uses a Microsoft SQL Server backend and the other uses Oracle. Both implementations must function in the same way. You can create an abstract test class named DBTestSuite which contains standard test code. You can then create two classes, SQLTestSuite and OracleTestSuite, which both derive from DBTestSuite. The derived classes need only implement the abstract Connect method. One test class will then connect to Microsoft SQL Server and the other to Oracle.

Further, you can create an EmptySQLTestSuite test class that derives from SQLTestSuite to test an empty Microsoft SQL Server database. To improve performance, you can override the particular test methods that do not make sense for testing an empty database.

If you use test class inheritance, the Test View window and Test List Editor display the test methods both in base classes and in child classes. To see which class a test is in, display the Class Name or Full Class Name columns in Test List Explorer. For more information, see How to: Customize Test Views.

Testing Private Methods

Using unit tests, you can test not only public methods but private methods also. As with public methods, unit tests for private methods are created automatically when you generate tests from the code you want to test. For more information, see How to: Test a Private Method and Unit Tests for Internal, Private, and Friend Methods.

Special Kinds of Unit Tests

The following table lists additional kinds of unit tests:

Unit Test Type

Description

data-driven unit tests

A data-driven test is a unit test that you configure to be called repeatedly for each row of a data source. The data from each row is available to each successive run of the test as input data. For more information, see Overview of Data-Driven Unit Tests.

ASP.NET unit tests

ASP.NET unit tests are used to exercise code in an ASP.NET application as it responds to page requests. ASP.NET unit tests are run inside the ASP.NET application being tested. For more information, see Overview of ASP.NET Unit Tests.

Smart device unit tests

Smart device unit tests are unit tests that run under the smart device host process on a smart device or emulator. For more information, see Overview of Smart Device Unit Tests

Web service unit tests

For information about Web service unit tests, see Unit Tests for Web Services.

See Also

Concepts

Anatomy of a Unit Test

Unit Tests and C++

Other Resources

Working with ASP.NET Unit Tests

Working with Data-Driven Unit Tests

Working with Smart Device Unit Tests

Managing Tests

Running Tests

Analyzing Test Results