我应尊敬的 John Skeet 先生的要求重新发布这个问题，他建议我设计一个简单的测试程序来隔离和演示我遇到的问题并重新发布这个问题。这个问题源于 this one ，所以如果这一切听起来很熟悉，请原谅我。您可能会从那个问题中收集到关于这个问题的额外详细信息。

我遇到的问题是 Assert.Throws<T>来自 NUnit 2.5.9。有时，它无法捕获在 TestDelegate 调用的方法中抛出的任何异常。我在下面的代码中以可重现的方式确定了这种行为。 (尽管这可能是 Fails On My Machine™ 的一个例子。

为了重现错误，我创建了一个包含两个 C# DLL 项目的解决方案:

• 第一个包含一个类，具有一个公共(public)方法。该方法是一种扩展方法，它封装了创建 SqlCommand 所需的逻辑。 , 填充其参数并调用 ExecuteScalar在上面。该项目不包含其他引用资料。
• 第二个包含一个具有两个方法的类，用于测试第一个 DLL 中的方法是否按预期工作。该项目引用第一个，并包括对 NUnit 框架的引用。没有引用其他程序集。

当我在调试器中单步执行测试时，我观察到以下内容:

1. Assert.Throws正确调用 ExecuteScalar<T>扩展方法。
2. 如预期的那样，参数值为空。
3. ExecuteScalar<T>测试其参数的空值。
4. 调试器确实命中并执行了包含throw new ArgumentNullException(...) 的行.
5. 执行 throw 之后, 应用程序的控制权不会立即转移到 Assert.Throws .相反，它在 ExecuteScalar<T> 的下一行继续.
6. 一旦下一行代码执行，调试器就会中断，并显示错误“Argument null exception was unhandled by user code”。

隔离此行为的源代码如下。

扩展方法

namespace NUnit_Anomaly
{
    using System;
    using System.Data;
    using System.Data.SqlClient;

    public static class Class1
    {
        public static T ExecuteScalar<T>(this SqlConnection connection, string sql)
        {
            if (connection == null)
            {
                throw new ArgumentNullException("connection");
            }

            if (sql == null)
            {
                throw new ArgumentNullException("sql");
            }

            using (var command = connection.CreateCommand())
            {
                command.CommandType = CommandType.Text;
                command.CommandText = sql;
                return (T)command.ExecuteScalar();
            }
        }
    }
}

测试用例

namespace NUnit_Tests
{
    using System;
    using System.Data.SqlClient;
    using System.Diagnostics;

    using NUnit.Framework;

    using NUnit_Anomaly;

    [TestFixture]
    public class NUnitAnomalyTest
    {

        [Test]
        public void ExecuteDataSetThrowsForNullConnection()
        {
            Assert.Throws<ArgumentNullException>(() => ((SqlConnection)null).ExecuteScalar<int>(null));
        }

        [Test]
        public void ExecuteDataSetThrowsForNullSql()
        {

            const string server = "MY-LOCAL-SQL-SERVER";
            const string instance = "staging";
            string connectionString = String.Format("Data Source={0};Initial Catalog={1};Integrated Security=True;",
                                                    server,
                                                    instance);

            using (var connection = new SqlConnection(connectionString))
            {
                Assert.Throws<ArgumentNullException>(() => connection.ExecuteScalar<int>(null));
            }
        }
    }
}

最终结果是测试在不应该失败的时候失败了。据我所知，Assert.Throws<T>应该捕获我的异常并且测试应该通过。

更新

我采纳了汉斯的建议并检查了异常(exception)对话框。我不是在处理抛出 异常时中断，而是在处理未处理的用户 异常时中断。显然，这就是调试器在抛出异常时中断到 IDE 的原因。清除复选框解决了问题，Assert.Throws<T>把它捡了起来。但是，如果我没有这样做，我不能直接按F5继续执行，否则异常会变成NullReferenceException。 .

所以现在的问题是:我可以在每个项目的基础上配置异常中断吗？我只想在测试时这样做，但一般情况下不会这样做。

最佳答案

实际发生的是 Assert.Throws 确实捕获了您的异常，但是 Visual Studio 无论如何都会在第一次异常时停止。您可以通过按 F5 来检查它； Visual Studio 将愉快地继续执行。

正如异常助手告诉您的那样，异常未被用户代码处理。所以我们知道 Visual Studio 出于某种原因不会将 NUnit 视为用户代码。

Visual Studio 实际上会以纯文本的形式告诉您，如果您知道在哪里查看:

堆栈跟踪中也有此事实的证据:

解决方案 1:使用带有调试符号的 NUnit 调试版本。那will get Visual Studio to regard NUnit as user code ，从而停止将您的异常视为“未被用户代码处理”。这不是微不足道的，但从长远来看可能会更好。

解决方案 2:在 Visual Studio 的调试设置中关闭“启用仅我的代码”复选框:

附言我不考虑避免使用 Assert.Throws<T> 的解决方法完全一样，但当然有办法做到这一点。

关于c# - NUnit:为什么 Assert.Throws<T> 没有捕获我的 ArgumentNullException？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4785342/