我已经准备好Mcconnell的" 代码完成 " 了一段时间.现在我在亨特和托马斯的" 实用程序员 "中再次阅读:使用断言!注意:我的意思是,不是单元测试断言Debug.Assert().
在SO问题之后什么时候应该使用Debug.Assert()？而当使用断言过例外领域类的断言是发展有用的,因为"不可能"的情况下,可以发现相当快.它们似乎很常用.据我理解的断言,在C#中,它们通常用于检查"不可能"值的输入变量.
为了尽可能简化和隔离单元测试,我用nulls和"不可能"的虚拟输入(如空字符串)来提供类和方法.
此类测试明确记录,它们不依赖于某些特定输入.注意:我正在练习Meszaros的"xUnit测试模式"描述为Minimal Fixture.
这就是重点:如果我有一个保护这些输入的断言,它们会炸毁我的单元测试.
我喜欢断言编程的想法,但另一方面我不需要强迫它.目前我想不出任何用途Debug.Assert().也许有一些我想念的东西？你有什么建议,他们真的有用吗？也许我只是高估了断言的用处？或者也许我的测试方式需要重新审视？
编辑:调试的最佳实践单元测试期间的断言非常相似,但它没有回答困扰我的问题:如果我Debug.Assert()按照我的描述进行测试,我是否应该关心C#？如果是的话,它们在哪种情况下真的有用？在我目前的观点中,这样的单元测试将Debug.Assert()没有必要.
另一点:如果你真的认为,这是一个重复的问题,只需发表一些评论.
从理论上讲,你是对的 - 详尽的测试使断言变得多余.理论上.在parctice中,它们仍然可用于调试测试,以及捕获可能尝试使用不符合其预期语义的接口的未来开发人员的尝试.
简而言之,它们仅用于单元测试的不同目的.他们在那里捕捉错误,这些错误本质上是在编写单元测试时不会产生的.
我建议保留它们,因为它们提供了程序员错误的另一级保护.
它们也是本地错误保护机制,而单元测试在被测试代码的外部.在压力下"无意中"禁用单元测试比在一段代码中禁用所有断言和运行时检查要容易得多.