Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
Unit Testing feature in Visual Studio 2012 has been very enthusiastically received by the developer community. Our focus during RC milestone was to respond to feedback we received from Visual Studio 11 Beta. This article talks about some of the new features that we have built during this milestone, many of which were driven by customer feedback.
Previously, when a test project was built, Test Explorer would perform an exhaustive search to discover the tests. Now we have implemented a Smart Test Discovery algorithm which significantly improves the time required for updates to appear on the Test Explorer Window. In fact, this is now so blindingly fast that for the first few times I would rebuild the solution just to make sure that discovery was happening.
This feature was introduced in Beta and so well-liked that we have now moved it into the Test Explorer tool bar.
When this feature is turned on, the tests are run automatically after every successful build. If there are failed tests from previous runs, they are executed first.
Previously, we were using the ExpectedException attribute on a Test Method to handle scenarios where the test would throw an exception. This approach has many limitations, primarily the ability to precisely identify the source of the exception. To address this we have added Assert.ThrowsException.
Test will fail if the specified exception is not thrown by the test code.
NOTE: Assert.ThrowsException is available only in Unit Test Library for Metro style apps. In conjunction, we have removed ExpectedException Attribute from Unit Test Library for Metro style apps.
Code Analysis is now enabled for Unit Test Library (Metro style apps).
The Portable Class Library project in Visual Studio 2012 RC enables you to write and build managed assemblies that work on multiple .NET Framework platforms. For example, you can create classes that contain shared business logic for desktop apps, Windows Metro style apps, and mobile apps, and you can then reference those classes from those projects.
We have converted the Unit Test Framework into a Portable Class Library.
We have enabled a shortcut menu in the Visual Studio Editor which allows you to run or debug the tests under the cursor.
Based on extensive feedback we received from customers, we have implemented the following features related to compatibility.
1. Test List Editor (.vsmdi) can now be opened in Visual Studio 2012 RC. This feature has been deprecated and you cannot run tests from this editor. You also cannot create new Test Lists in Visual Studio 2012 RC. We recommend that you use Test Categories to group tests and maintain test lists.
2. All Test Templates in Visual Studio 2010 (Ordered Tests, Generic Tests, Web Performance Tests & Load Tests) can now be added in a Test Project. They will be listed in the Test Explorer. You can run them from the Test Explorer.
We have added a number of articles in MSDN for Unit Tests. Check out the Verifying Code by Using Unit Tests link for an overview and pointer to various walkthroughs and detailed articles.
If you have feature suggestions for Unit Testing, you can log them at Visual Studio User Voice.
You can log bugs at Microsoft Connect.
You can also discuss your issues in MSDN Forums.
Is it possible to extend the test types? Is there any documentation on how this could be done?
We'd like to add some additional functionality to make it easier to deal with asynchronous tests.
More tools and features for Manual testers have been introduced in Visual Studio 2012 update 1 and update 2 which can be found in below link
So, here I am 18 months later, and 4 updates into VS2013 and asking, where is Assert.ThrowsException in the regular MS Test unit test framework? Any update on this? Is it finally going to make it into VS 14? Heck, I can even provide a sample implementation that matches (as close as I can) the pattern used by the standard Assert and StringAssert classes--it's a shame you guys made the HandleFail and CreateCompleteMessage methods internal, as well as the AssertionFailure event handler. :( Then users could more easily have extended the assertions provided by MS Test out of the box.