Creating and Running Unit Tests for Existing Code
This section provides instructions about how to create unit tests, gives some background information about how to test methods that have restricted access, and describes the various assert classes that you can use in unit tests.
Use the following topics to help you create and run unit tests:
Create and run a unit test: Describes how to create a unit test that is populated with data for the method being tested using the Visual Studio Application Lifecycle Management testing tools. You can then add Assert statements to apply testing logic to your unit tests.
You can also create a blank test class and supply the details manually. Basic unit tests are ideal for test-driven development.
Additionally, you can create a unit test for an .EXE or a .DLL for which you do not have access to the source code.
Create a data-driven unit test: You can create a unit test that retrieves values from a data source instead of typing values into a test method.
Create unit tests that can access internal, private, and friend methods: Using Visual Studio Application Lifecycle Management you can create unit tests with the ability to access internal, private and friend methods.
The use of Accessors has been deprecated in Visual Studio 2010 and will not be included in future versions of Visual Studio.
Determining whether your unit test passed or failed: You can create various kinds of assert statements, which you can use in unit tests for purposes such as comparing values or collections or checking for specific test results.
Running tests as a 64-bit process: You can now run tests and collect code coverage information as a 64-bit process.
Run unit tests that target the .NET Framework 3.5 and test SharePoint applications: For Visual Studio 2010, the default target version of the .NET Framework in test projects is the .NET Framework 4. If you upgrade test projects from Visual Studio 2008, they are upgraded to target the .NET Framework 4 by default. You can edit the project properties and explicitly re-target the project to the .NET Framework 3.5. Targeting the .NET Framework 3.5 lets you test SharePoint 2010 applications.
In the .NET Framework 3.5, multitargeting is supported for test projects that contain only unit tests. The .NET Framework 3.5 does not support any other test type, such as coded UI or load test. The re-targeting is blocked for test types other than unit tests.
Running tests in parallel to speed up test execution time: You can use a computer that has multiple CPUs or a single CPU with multiple cores to run your unit tests in parallel to speed up the overall test execution time.
Running unit tests that collect useful information about the machine on which they are running: You can create or modify a test setting and use it when you run your unit tests to collect system information and IntelliTrace data.
Running unit tests on multiple machines: You can use a group of computers to run unit tests remotely and concurrently on several computers by using a test controller and one or more test agents that are specified in a test setting.
Using multiple machines requires Visual Studio 2010 Ultimate.
Perform stress and performance analysis by using load tests for your unit tests: You can create a load test and add your unit tests to it to help isolate performance and stress issues in your application.
Creating and using load tests requires Visual Studio 2010 Ultimate.
Extending unit tests using the unit testing framework: You can use the Microsoft.VisualStudio.TestTools.UnitTesting namespace to create custom unit tests.
Gain knowledge of the differences and additional information that you need about unit tests for C++, generic methods, Web Services, and smart devices.
You can run automated tests locally from Microsoft Visual Studio 2010. Or, you can run your automated tests remotely by using test agent controllers and test agents.