.net - 如何使用代码契约进行单元测试

Question

使用 .NET 4.0 代码契约执行 TDD 的最佳实践建议是什么？

我想具体来说，我的问题是，考虑到 TDD 的一个要点是允许代码自我记录并且契约(Contract)现在提供了一部分文档，代码契约(Contract)是否应该以与其他代码相同的方式进行测试？

Answer 1

这取决于您如何使用合约以及您正在开发的应用程序类型。

首先:您当然不想单独测试断言和后置条件( Contract.Assert 、 Contract.Assume 、 Contract.Ensures 和 Contract.EnsuresOnThrow )。
我认为这样做没有实际值(value) - 因为它们已经在运行时由重写器验证，即使没有测试，您也会很快发现失败。
然而，在经过良好测试的应用程序中，任何后置条件或断言都不应该失败——即使是在无效输入上。因此，如果您的所有测试(甚至是测试处理无效数据的测试!)都通过而没有单个后置条件/断言失败，则您的后置条件和断言可以被视为“已测试”。
为此，您可能希望在测试中使用“Assert.Fail”来处理 ContractFailed 事件。

现在“有趣”的部分是先决条件:
你在开发一个库吗？然后，如果您的时间/预算允许，您绝对应该测试它们(更糟糕的是不测试实际逻辑)。
特别是，如果您正在使用“Contract.Requires ”重载，它会在契约(Contract)失败时引发特定异常，您应该像使用“if-throw”-constructs 的常规参数验证一样测试它们。

如果您不是在编写库，我不会说测试先决条件真的很有必要——它们不是真正的业务需求，而是调试的 helper 。
为每个 ArgumentNullException 编写一个单元测试真的很无聊。如果参数是 null，方法应该抛出.
如果您忘记了方法中的此验证代码(意思是:特定的 Contract.Requires)，您可能也会忘记单元测试。因此，参数验证测试为您的(非库)代码带来的附加值与连接值相比非常低。

总结一下:不要测试后置条件和断言。测试先决条件 - 但仅限于库(也可能是像库一样使用的代码部分)。