ExpectedExceptionAttribute is not working in MSTes

2019-03-27 21:28发布

问题:

This is weird, but all of a sudden the ExpectedExceptionAttribute quit working for me the other day. Not sure what's gone wrong. I'm running VS 2010 and VS 2005 side-by-side. It's not working in VS 2010. This test should pass, however it is failing:

[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void Test_Exception()
{
    throw new ArgumentNullException("test");
}

Any ideas? This really sux.

回答1:

Not to resurrect a dead thread, but I came across this when this all the sudden happened to me, in case it can help others. I did finally track down what the problem was, which may correlate with what Jon found. The ExpectedException attribute appears to only work if the project is recognized as a TestProject. (Not just a .Net assembly)

Unload the project, edit the csproj file and check that the following setting is there:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

(Assuming VS2010 project) Reload the project and rebuild. ExpectedException tests should now pass.

We ran into this issue when standardizing tests from NUnit to MSTest (Thank you TFS CI Build) and found that After replacing Assert.Throws<> beautiful simplicity & flexibility with [ExpectedException(Type)] crap, (Not to mention losing [TestCase()]!) the ExpectedException tests failed for no reason. Toggle back to NUnit with ExpectedException, no problem, MSTest refuses to run it.

Needless to say I will be pushing to get NUnit back, after finding: http://blog.shawnewallace.com/2011/02/running-nunit-tests-in-tfs-2010.html



回答2:

I have another answer, which has no need to edit the csproj file. It seems that the root cause was just a missing reference. I added Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll to the project's references and using Microsoft.VisualStudio.TestTools.UnitTesting; to the code files. The dll can be found in

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\

or

C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\

I hope I could help anyone save some time.



回答3:

I've had the same issue, but finally managed to get it working. Not really sure how but here's a list of things I did between it not working to when it started working again.

  • Converted the project being tested to .NET 4
  • Turned off CodeCoverage
  • Turned CodeCoverage back on again
  • Did a RebuildAll on the test project

Not sure which bit fixed it though. Anyway, hope this helps!



回答4:

This thread came up on a Google search and since I encountered this today too, but for a different reason, I'll add another possible anser here.

I had unit tests for some function with the [ExpectedException] attribute in place, but a recent code update made the function that was tested async to improve performance.

This caused these unit tests to fail. The simple solution was to also make the unit-test async, return Task and await the function-call:

[TestMethod]
[ExpectedException(typeof(Exception))]
public async Task UnitTestAnAsyncFunction()
{
    await sut.DoStuffAsync();

    //Assert
    //ExpectedException
} 


回答5:

And another answer. Today I upgraded a Visual Studio 2008 (net35) MSTest project to Visual Studio 2017 (net462). The answer from Marcel Kalinowski refers to a missing Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll - in my case, it was there, but the reference was pointing to the old VS2008 version, while the rest was upgraded. No exclamation mark, no compilation errors and all unit tests worked as expected except for those with a [ExpectedException] attribute.

Removing the reference and adding the current version (10.0.0.0 for me) made those tests work again.