NUnit测试中如何优雅实现含Null约束的TestCase参数化测试？

方案1：利用[SetUp]拆分测试，避免初始化重复 #

如果担心拆分测试会重复复杂初始化代码，NUnit的[SetUp]特性正好解决这个问题——把初始化逻辑放在标记为[SetUp]的方法里，每个测试方法执行前都会自动运行这段代码，无需重复编写。

代码示例：

[TestFixture]
public class FooTests
{
    // 存放需要初始化的依赖对象
    private SomeDependency _sharedDependency;

    [SetUp]
    public void Setup()
    {
        // 复杂初始化逻辑只写一次
        _sharedDependency = new SomeDependency();
        // 其他初始化步骤...
    }

    [Test]
    public void Foo_InputA_ReturnsNull()
    {
        var result = Foo("A");
        Assert.That(result, Is.Null);
    }

    [Test]
    public void Foo_InputB_ReturnsNonNull()
    {
        var result = Foo("B");
        Assert.That(result, Is.Not.Null);
    }
}

这种方式最直观，每个测试只关注单一断言，符合单一职责原则，完全规避了属性参数的类型限制。

方案2：用内联TestCaseData配合TestCaseSource，保持参数化风格 #

如果偏好参数化测试的紧凑写法，可以把TestCaseData直接定义在测试类内部，无需单独新建类，比常规TestCaseSource更简洁：

[TestFixture]
public class FooTests
{
    private static readonly IEnumerable<TestCaseData> FooTestCases = new List<TestCaseData>
    {
        new TestCaseData("A").Returns(null),
        new TestCaseData("B").Returns(Is.Not.Null)
    };

    [Test, TestCaseSource(nameof(FooTestCases))]
    public object Foo_ReturnsExpectedValue(string input)
    {
        // 复用SetUp中初始化的依赖
        return Foo(input);
    }

    [SetUp]
    public void Setup()
    {
        // 复杂初始化...
    }
}

这里利用TestCaseData.Returns()方法直接指定预期约束，测试方法内无需写分支断言，保持了参数化测试的简洁性。

方案3：封装断言辅助方法，简化分支逻辑 #

如果坚持用单个参数化测试方法，可以把断言逻辑抽离到辅助方法中，避免测试方法内的冗余分支：

[TestFixture]
public class FooTests
{
    [TestCase("A", true)]
    [TestCase("B", false)]
    public void Foo_ReturnsExpectedNullState(string input, bool shouldBeNull)
    {
        var result = Foo(input);
        AssertNullState(result, shouldBeNull);
    }

    private void AssertNullState(object result, bool shouldBeNull)
    {
        if (shouldBeNull)
        {
            Assert.That(result, Is.Null);
        }
        else
        {
            Assert.That(result, Is.Not.Null);
        }
    }

    [SetUp]
    public void Setup()
    {
        // 复杂初始化...
    }
}

这种方式将断言逻辑封装后，测试方法本身依然简洁，同时复用了初始化代码。

最佳实践建议 #

• 优先选择方案1：拆分测试方法配合[SetUp]，测试逻辑最清晰，便于维护和定位问题，符合测试的单一职责原则。
• 如果需要参数化测试的紧凑性，选择方案2的内联TestCaseData写法，比单独的TestCaseSource类更简洁。
• 尽量避免在测试方法中编写复杂分支逻辑，保持测试代码的直白性，降低维护成本。

内容的提问来源于stack exchange，提问作者xavier