使用ExpectedException时要谨慎，因为它可能导致如下所示的几个陷阱:

Link

在这里:

http://xunit.github.io/docs/comparisons.html

如果需要测试异常，有一些不太受欢迎的方法。您可以使用try{act/fail}catch{assert}方法，该方法对于除了ExpectedException之外不直接支持异常测试的框架非常有用。

更好的选择是使用xUnit。NET，这是一个非常现代的、前瞻性的、可扩展的单元测试框架，它已经从所有其他错误中吸取了教训，并进行了改进。Assert就是这样一种改进。它为断言异常提供了更好的语法。

你可以找到xUnit。NET在github: http://xunit.github.io/

这取决于您使用的测试框架?

例如，在MbUnit中，您可以用一个属性指定预期的异常，以确保您得到的是真正预期的异常。

[ExpectedException(typeof(ArgumentException))]

如果你使用NUNIT，你可以这样做:

Assert.Throws<ExpectedException>(() => methodToTest());

也可以存储抛出的异常以便进一步验证:

ExpectedException ex = Assert.Throws<ExpectedException>(() => methodToTest());
Assert.AreEqual( "Expected message text.", ex.Message );
Assert.AreEqual( 5, ex.SomeNumber);

参见:http://nunit.org/docs/2.5/exceptionAsserts.html

有一个很棒的库叫做NFluent，它可以加速和简化你编写断言的方式。

编写抛出异常的断言非常简单:

    [Test]
    public void given_when_then()
    {
        Check.ThatCode(() => MethodToTest())
            .Throws<Exception>()
            .WithMessage("Process has been failed");
    }

对于“Visual Studio Team Test”，似乎您将ExpectedException属性应用到测试的方法。

文档中的示例:使用Visual Studio团队测试的单元测试演练

[TestMethod]
[ExpectedException(typeof(ArgumentException),
    "A userId of null was inappropriately allowed.")]
public void NullUserIdInConstructor()
{
   LogonInfo logonInfo = new LogonInfo(null, "P@ss0word");
}

作为一种替代方法，您可以尝试测试异常实际上是在您的测试中的下两行中抛出的。

var testDelegate = () => MyService.Method(params);
Assert.Throws<Exception>(testDelegate);