.NET 4.0 代码合同——它们将如何影响单元测试？

Question

例如这个article 介绍了他们。

有什么好处？

静态分析看起来很酷，但同时它会阻止在单元测试中将 null 作为参数传递的能力。 （如果您按照文章中的示例进行操作）

关于单元测试的话题——考虑到现在的情况，如果你已经练习过自动化测试，那么代码合同肯定没有意义吗？

更新

玩过 Code Contracts 我有点失望。例如，根据接受答案中的代码：

public double CalculateTotal(Order order)
{
    Contract.Requires(order != null);
    Contract.Ensures(Contract.Result<double>() >= 0);
    return 2.0;
}

对于单元测试，您仍然必须编写测试以确保不能通过 null，并且如果合同是 业务逻辑，则结果大于或等于 0 >。换句话说，如果我要删除第一个合同，任何测试都不会中断，除非我专门对此功能进行了测试。然而，这是基于不使用更好（最终等）版本的 Visual Studio 中内置的静态分析。

基本上，它们都归结为编写传统 if 语句的另一种方式。我实际使用TDD, with Code Contracts 的经验说明了原因以及我是如何做到的。

Answer 1

合约允许你说出代码的实际目的是什么，而不是让代码执行的任何随机参数都被传递给它作为从编译器或下一个读者的角度来看的定义代码。这可以显着改善静态分析和代码优化。

例如，如果我声明一个整数参数（使用协定表示法）在 1 到 10 的范围内，并且我在函数中声明了一个相同大小的本地数组，该数组由参数索引，则编译器可以判断没有下标错误的可能性，从而产生更好的代码。

您可以声明 null 是合同中的有效值。

单元测试的目的是验证动态代码实现了它所声明的任何目的。仅仅因为您已经为函数编写了合约，并不意味着代码可以做到这一点，或者静态分析可以验证代码是否可以做到这一点。单元测试不会消失。

Answer 2

一般来说它不会干扰单元测试。但正如我所见，您提到了一些关于 TDD 的内容。

如果我从这个角度考虑，我猜它可能/可能会改变标准程序的程序

• 创建方法（只是签名）
• 创建单元测试 -> 实施测试
• 运行测试：让它失败
• 实现该方法，将其修改到最后以使其正常工作
• 运行测试：看它通过
• 重构您的（可能是混乱的）方法体
• （重新运行测试只是为了看看你没有破坏任何东西）

这将是真正困难的全功能单元测试过程。在这种情况下，我猜您可以在第一点和第二点之间插入代码合同，例如

• 创建方法（只是签名）
• 为方法输入参数插入代码协定
• 创建单元测试 -> 实施测试
• ...

我目前看到的优势是您可以编写更简单的单元测试，因为您不必检查所有可能的路径，因为您定义的合同已经考虑了一些路径。它只是给你额外的检查，但它不会取代单元测试，因为代码中总会有更多的逻辑，更多的路径必须像往常一样用单元测试来测试。

编辑

我之前没有考虑过的另一种可能性是在重构部分添加代码协定。基本上作为保证事情的额外方式。但这在某种程度上是多余的，因为人们不喜欢做多余的事情......

Answer 3

有什么好处？

假设你想确保一个方法永远不会返回null。现在使用单元测试，您必须编写一堆测试用例，在其中调用具有不同输入的方法并验证输出不为空。 问题是，您无法测试所有可能的输入。

使用代码契约，您只需声明该方法永远不会返回null。如果无法证明这一点，静态分析器就会抱怨。如果它没有抱怨，您就知道您的断言对于所有可能的输入都是正确的。

更少的工作，完美的正确性保证。有什么不喜欢的？

Answer 4

我不认为单元测试和合同相互干扰太多，如果有什么合同应该有助于单元测试，因为它消除了为无效参数添加繁琐重复测试的需要。契约指定了你可以从函数中得到的最小值，而单元测试试图验证一组特定输入的实际行为。考虑这个人为的例子：

public class Order
{
    public IEnumerable Items { get; }
}

public class OrderCalculator
{
    public double CalculateTotal(Order order)
    {
        Contract.Requires(order != null);
        Contract.Ensures(Contract.Result<double>() >= 0);

        return 2.0;
    }
}

很明显，代码满足合同要求，但您仍需要进行单元测试来验证它的实际行为是否符合您的预期。