c# - 单元测试是否使 Debug.Assert() 变得不必要？

Question

我准备好麦康奈尔的“Code Complete”已经有一段时间了。现在我在 Hunt & Thomas 的“The Pragmatic Programmer”中再次阅读它:使用断言! 注意:不是单元测试断言，我的意思是 Debug.Assert()。

遵循 SO 问题 When should I use Debug.Assert()?和 When to use assertion over exceptions in domain classes断言对开发很有用，因为可以很快找到“不可能”的情况。而且它们似乎很常用。据我了解，断言在 C# 中通常用于检查输入变量的“不可能”值。

为了使单元测试尽可能简洁和独立，我使用 null 和“不可能的”虚拟输入(如空字符串)来提供类和方法。

此类测试明确记录，它们不依赖于某些特定输入。 注意:我正在练习 Meszaros 的“xUnit 测试模式”所描述的 Minimal Fixture .

这就是重点:如果我有一个保护这些输入的断言，它们会破坏我的单元测试。

我喜欢断言式编程的想法，但另一方面我不需要强制它。目前我想不出 Debug.Assert() 有什么用处。也许我想念什么？您有什么建议可以真正有用吗？也许我只是高估了断言的用处？还是我的测试方式需要重新审视？

编辑:Best practice for debug Asserts during Unit testing非常相似，但它没有回答困扰我的问题:如果我像我描述的那样进行测试，我应该关心 C# 中的 Debug.Assert() 吗？如果是，它们在什么情况下真正有用？在我目前的观点中，这样的单元测试将使 Debug.Assert() 变得不必要。

还有一点:如果您真的这么认为，这是一个重复的问题，请发表评论。

Answer 1

从理论上讲，您是对的 - 详尽的测试使断言变得多余。理论上。实际上，它们对于调试您的测试以及捕捉 future 开发人员可能尝试使用不符合其预期语义的接口(interface)的尝试仍然很有用。

简而言之，它们只是服务于与单元测试不同的目的。他们在那里是为了发现在编写单元测试时本质上不会犯的错误。

我建议保留它们，因为它们提供了另一层保护，防止程序员犯错误。

它们也是一种本地错误保护机制，而单元测试在被测试代码的外部。在压力下“无意中”禁用单元测试比禁用一段代码中的所有断言和运行时检查要容易得多。