This would be really helpful. With UI tests, the process of getting the application to a particular state to test something can be time consuming. It doesn't make sense to apply the unit test methodology of test one thing and one thing only when the test can take minutes to run and there are lots of values to test.

I think a parameter will serve the purpose. We can suggest playback engine with this parameter that it needs to fail or continue the test. We can keep this parameter as optional and by default value will be fail.

I think the concept of "Verify" semantics are required - similar to what is used in GTEST. Verify() is exactly the same as an Assert() except that Verify() does not terminate the test on a failure - it 'notes' the error but continues.

At the end of the test, if any Verify's failed, the test is failed (warnings tend to be ignored). This approach allows a lot more information to be gleamed from a failure, especially where MsTest is being used for, perhaps, functional UI testing and the test might contain many assertions.

Will an overload to the Assert Methods which specify that an assertion failure should be a warning suffice?
By default an assertion failure results in a test case failure. If this new Assert overload method is used, a warning will be logged in the test results.