.NET 4.0代码契约 - 它们将如何影响单元测试？

Question

例如,本文介绍了它们.

有什么好处？

静态分析似乎很酷,但同时它会阻止在单元测试中传递null作为参数的能力.(如果您按照文章中的示例进行操作)

关于单元测试的主题 - 如果您已经实施自动化测试,那么现在肯定没有任何关系可以代码合同吗？

更新

玩过代码合约后,我有点失望.例如,根据接受的答案中的代码:

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

对于单元测试,您仍然必须编写测试以确保无法传递null,并且如果契约是业务逻辑,则结果大于或等于零.换句话说,如果我要删除第一个合同,除非我特意测试了这个功能,否则没有测试会中断.这是基于不使用内置于Visual Studio的更好(终极等)版本中的静态分析.

从本质上讲,它们都归结为编写传统if语句的另一种方式.我实际使用TDD的经验,代码合同显示了原因,以及我如何去做.

Answer 1

我不认为单元测试和合同会相互干扰那么多,如果有任何合同应该有助于单元测试,因为它不需要为无效参数添加繁琐的重复测试.合同指定了函数的最小值,而单元测试则尝试验证特定输入集的实际行为.考虑这个人为的例子:

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;
    }
}

显然,代码满足合同,但您仍然需要单元测试来验证它实际上是否符合您的预期.

Answer 2

有什么好处？

假设您要确保方法永远不会返回null.现在使用单元测试,您必须编写一组测试用例,您可以使用不同的输入调用方法,并验证输出不为null.麻烦的是,你无法测试所有可能的输入.

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

减少工作量,完美正确保证.有什么不喜欢的？