我今天应该仍然使用Debug.Assert吗？

我最近遇到了一些新编写的代码，这些代码中散布着许多Debug.Assert（C＃）。

尽管总体上使用了TDD，BDD和单元测试，我们是否仍应广泛使用它？

我看不出您不应该使用Assert的任何原因。通过这样做，您已经认识到需要警卫（例如前提条件和不变式），并且正在朝着“ 按合同设计”的方向发展。断言只是实现这一目标的一种方法...

// Precondition using Asert
void SomeMethod(Foo someParameter)
{
    Debug.Assert(someParameter != null)
}

// Precondition using If-Then-Throw
void SomeMethod(Foo someParameter)
{
    if (someParameter == null)
        throw new ArgumentNullException("someParameter");
}

// Precondition using Code Contracts
void SomeMethod(Foo someParameter)
{
    Contract.Requires(someParameter != null);
}

// Precondition using some custom library
void SomeMethod(Foo someParameter)
{
    Require.ArgumentNotNull(() => someParameter);
}

都是实现同一目标的方法：代码的健壮性。它仅取决于选择一个选项，其中Assert是有效的选择。

请注意，到目前为止，我还没有提到单元测试，因为它们可以完成非常不同的事情。单元测试通过行使保护措施来正式证明代码的健壮性：

[Test]
void SomeMethod_WhenGivenNull_ThrowsArgumentNullException()
{
    delegate call = () => someObject.SomeMethod(null);

    Assert.That(call).Throws<ArgumentNullException>();
}

这是完全不同的断言...

**请注意，在某些框架中，对于断言失败进行单元测试实际上是相当困难的，因为断言失败会降低整个运行时间，因此可能更希望使用其他选项之一... *

我认为断言和单元测试是我工具箱中的两个不同工具。有些东西更适合其中一种，而有些则更适合另一种。

举例来说，如今，我主要使用断言来验证非公共方法的参数。

我现在将Debug.Assert视为过早的优化。除非您真的需要性能，否则禁止在发布模式下声明“ Assert”可以将错误隐藏的时间更长。

正如MattDavey指出的那样，代码契约可以提供静态检查而不是动态检查，这是一个更好的选择，如果不可用，我更喜欢使用Trace.Assert或简单的旧代码。if(x) throw SomeException;