Upgrade Visual Studio 2010 unit test projects
Visual Studio 2012 includes test project compatibility with Visual Studio 2010 SP1 test projects. For example, test projects that you created with Visual Studio 2010 SP1 can be opened using Visual Studio 2012 without any upgrade. Therefore, your team can use both Visual Studio 2010 SP1 and Visual Studio 2012 to work with same test project. For more information, see Upgrading tests from Visual Studio 2010.
Visual Studio 2012 introduces several changes for unit testing. Because of these changes, it is important to understand the compatibility issues between previous versions of Visual Studio and Visual Studio 2012. Among the changes to unit testing, a significant change is that Visual Studio 2012 includes more than one test project template, including a unit test project template. New unit tests are added to the new unit test project template. Unit tests can also be included in another new test project template called the coded UI test project template. For more information about the new test project templates, see Upgrading Tests from Earlier Versions of Visual Studio. The new unit test projects no longer include a test settings file by default. By excluding the test settings file, the performance of your unit tests improves. For compatibility, you can still use your existing test projects that you created using Visual Studio 2010. However, we recommend that you remove the test settings file associated with the test project for performance reasons unless you have a specific need for the test settings file. For example, you might choose to retain the test settings file if your unit tests run in a distributed environment, or you need to collect specific diagnostic data. If you have a similar need using the new unit test project template, or coded UI test project template, you can manually add a test settings file to them as well.
Existing unit tests in your Visual Studio 2010 SP1 test projects will work seamlessly between Visual Studio 2010 SP1 and Visual Studio 2012. No changes are made to the test project files when a Visual Studio 2010 test project containing your unit tests is opened in Visual Studio 2012, or vice-versa.
Visual Studio 2010 can't open a C++/CLI project that targets the 11.0 toolset—that is, a project created in Visual Studio 2012. This restriction applies to all C++/CLI projects, not just C++/CLI unit test projects.
You can run the new unit tests using vstest.console.exe from the command line. For more information about using vstest.console.exe, see VSTest.Console.exe command-line options, or run the command by using the help switch: vstest.console.exe /?. You can continue to run your existing unit tests using MStest.exe. For more information, see Run automated tests from the command line using MSTest and MSTest.exe command-line options.
Another significant change is the new Test Explorer. In Visual Studio 2012, some of the testing windows you might be familiar with from previous version of Visual Studio have been deprecated, such as the Test View window. Test Explorer is designed to better support developers and teams who incorporate unit testing in their software development practices. For more information, see Run unit tests with Test Explorer.
Here are some issues to be aware of when you migrate unit tests between Visual Studio 2010 SP1 and Visual Studio 2012:
Unit Test functionality
Test lists (.vsmdi files) are deprecated in Visual Studio 2012.
You will no longer be able to create new test lists (.vsmdi files) or run test lists from Visual Studio.
Private accessors are deprecated in Visual Studio 2012.
In previous versions of Visual Studio, you could use Publicize to specify an internal application programming interfaces (API) and create public counterpart API that you can call in your tests, which would in turn, call into the internal APIs of your product. You could then use code generation to create test stubs and generate code snippet inside that stub.
You will no longer be able to create private accessors.
Test Impact is removed
Sharing of run results through TRX logs from Test Explorer.
You can still get TRX logs from both the command line and Team Build.