Unit Test Explorer is good but is not very keyboard-friendly. I liked the keyboard shortcuts in VS2010 that allowed me to run or debug all or a subset of tests without leaving the editor and without touching the mouse (i.e. CTRL R, T; CTRL R, C; CTRL R, N; CTRL R, F, CTRL R, D and the debug equivalents CTRL R, CTRL T, etc.). Not sure if these just didn't make the Beta, but would like to see them reinstated for RC.

Having said that, "Run Tests After Build" is a welcome addition (and gets us closer to continuous testing without a 3rd party like NCrunch), but it is currently hidden away in the menus and should be added to the Unit Test Explorer as a Toolbar button.

While an Automated Test in Visual Studio can be linked to multiple Manual Test Cases in Microsoft Test Manager (MTM), only ONE of the associated Manual Test Cases is marked as run / passed / failed when the Automated Test is run.

[ Current Behavior ]
1. Link an Automated Test Method in Visual Studio / TFS with a Manual Test Case in Microsoft Test Manager (MTM) / TFS, via the Test List Editor or 'tcm.exe' tool
2. Link the same Automated Test Method from Step 1 with another Manual Test Case in Microsoft Test Manager (MTM) / TFS, via the Test List Editor or 'tcm.exe' tool
3. Run the Automated Test Method, observe Test Result (via Visual Studio, MSTest, or 'tcm.exe')
4. Publish the Test Results to TFS, via the 'tcm.exe' tool (if required)
5. Use Microsoft Test Manager or Report Manager to analyze the Test Results of the Manual Test Cases; notice that only ONE of the Manual Test Cases appears to even have been run.

[ Expected Behavior ]
When an Automated Test Method that is associated with multiple Manual Test Cases is run, the obvious expected result would be that all associated Manual Test Cases are marked with the result of the Automated Test Method upon publishing the Test Results.

[ Justification ]
While it would be nice to have one-to-one relationships between Automated and Manual Tests, this is unrealistic in a real-world scenario, especially when managing pre-existing test plans for large enterprise applications. It is not only feasible for an Automated Test to exercise the steps from several Manual Tests, but in many cases it is acutally preferred.

Providing the ability to associate a single Automated Test with multiple Manual Tests serves absolutely no purpose if the RESULTS are only associated with a single Manual Test.

I am running a big mstest suite from the command line that takes about 15 minutes to complete. Once started the output to the command window is as below...

Microsoft (R) Test Execution Command Line Tool Version 10.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.

Loading SetupTestRun.testrunconfig...
Loading Test.BusinessLibrary\All.orderedtest...
Starting execution...

It remains like this until the test finishes and then dumps all the results to the screen in one big batch. Is there anyway to get a running progress of the tests to the command window so I can see a) how far it has progressed and b) what has passed and failed?

When a large number of tests is being run often, these many test runs should not be configured with heavyweight data collectors and bloat TFS with data that nobody will look at anyway, eventually sometimes even crashing the database. In the 95 % of passing tests nobody will probably care about analysing video or IntelliTrace. But people do want to have that data for the 5% of failing tests without having to kick off that test run once again with different test settings, possibly only to find out that the problem is not being reproduced.

Thus it would be nice if there was a way to have the heavyweight collectors configured for the runs, but have them save data only on failures, so you have the best of both approaches.

The video collector is designed already in a way that lets the customer choose not to save on passing tests and IntelliTrace collector is behaving like this all the time, not even giving the customer the choice to store the data on successful runs.

Wouldn't it be nice if that kind of behavior could be configured for all collectors in the same way?

Test Automation has not moved on in years from Hybrid frameworks. eg. Keyword Data Driven (KDD) a few players have worked with more advanced frameworks.

I have seen plenty of talk around advanced solutions for Visual Studio one example below.

http://social.msdn.microsoft.com/Forums/en-US/vsautotest/thread/944b33b3-f650-4dd8-a035-c807cbb2aadf

What surprises me is the poor progress in the Coded UI world. After all what we have is a full develoment environment. If something doesn't exist then surely the community would have listened and created advanced features for Coded UI.

But we still seem to have a solution that nothing better than extended Unit Tests.

It is possible to write a script-less 5th generation framework in QTP it has been done. I worked as part of the team that developed the solution. The GUI for that solution was developed in Visual Studio.

In the QTP solution the keywords, Data and objects were evaluated at runtime by the framework code this was then assemble in memory to run as an automated script. This process was invisible to QTP and QC as far as these tools were concerned they were running a full automation script.

The real up-side with this methodology was the reduction of around 95% of the code required to run automation. This 95% is created at run time. The framework allowed for coded components to be called as well along side the script-less parts.

The upside is fast development of automation...

1. simply because the process is faster.
2. Because manual testers can create automated tests.

I am testing a winform app using (VS 2012 Update 2). There is a login for the app that takes quite a bit of time that I'd like to avoid for each test, so I am setting CloseOnPlaybackCleanup to false to keep the application open in between tests.

All tests within my Coded UI framework for the application inherit from a base class. Note that the ApplicationUnderTest.Launch and setting of CloseOnPlaybackCleanup to false are called within the MyTestInitialize of this base test class. Any given test may open mulitple windows depending on what it's testing, so within MyTestCleanup of that base class, I want to close all open forms except for the main application window so that the application is in a clean state for the next test and all that is open is the main application window.

Our goal is that each individual test case make a best effort to close all windows that it opened. However, in the case where the individual test case did not clean up the windows due to unexpected windows or test failure, I want the base class to clean up anything left.

My suggestion is Visual Studio to either close all forms except for the main application window in between tests when CloseOnPlaybackCleanup is false, or a good performing way to discover all open forms associated to the application, so that I can then loop through them and close them.