unit-testing - Assert.Fail() 被认为是不好的做法吗？

Question

我在进行 TDD 时经常使用 Assert.Fail。我通常一次进行一个测试，但是当我对稍后想要实现的事情有了想法时，我会快速编写一个空测试，其中测试方法的名称指示我想要以待办事项列表的形式实现的内容。为了确保我不会忘记，我在正文中放置了一个 Assert.Fail() 。

在尝试 xUnit.Net 时，我发现他们没有实现 Assert.Fail。当然，您始终可以 Assert.IsTrue(false) 但这也不能传达我的意图。我的印象是 Assert.Fail 不是故意实现的。这被认为是不好的做法吗？如果是这样为什么？

<小时/>

@马丁·梅雷迪思 我不正是这么做的。我首先编写测试，然后实现代码以使其工作。通常我会同时想到几个测试。或者当我在做其他事情时我会考虑编写一个测试。那时我写了一个空的失败测试来记住。当我开始编写测试时，我完全以测试为先。

@吉梅 这看起来是个好主意。被忽略的测试不会失败，但它们仍然显示在单独的列表中。必须尝试一下。

@马特·豪威尔斯 好想法。在这种情况下，NotImplementedException 比 assert.Fail() 更好地传达意图

@米奇·小麦 这就是我一直在寻找的。看来它被排除在外是为了防止它被我以另一种方式滥用。

Answer 1

对于这种情况，我没有调用 Assert.Fail，而是执行以下操作(在 C#/NUnit 中)

[Test]
public void MyClassDoesSomething()
{
    throw new NotImplementedException();
}

它比 Assert.Fail 更明确。

似乎普遍认为使用比 Assert.Fail() 更明确的断言更好。大多数框架必须包含它，因为它们没有提供更好的选择。例如，NUnit(和其他)提供 ExpectedExceptionAttribute 来测试某些代码是否引发特定类的异常。然而，为了测试异常的属性是否设置为特定值，不能使用它。相反，你必须求助于 Assert.Fail:

[Test]
public void ThrowsExceptionCorrectly()
{
    const string BAD_INPUT = "bad input";
    try
    {
        new MyClass().DoSomething(BAD_INPUT);
        Assert.Fail("No exception was thrown");
    }
    catch (MyCustomException ex)
    {
         Assert.AreEqual(BAD_INPUT, ex.InputString); 
    }
}

xUnit.Net 方法 Assert.Throws 使这变得更加简洁，而不需要 Assert.Fail 方法。通过不包含 Assert.Fail() 方法，xUnit.Net 鼓励开发人员寻找和使用更明确的替代方案，并在必要时支持创建新断言。