合同设计(DbC)和测试驱动开发的最佳实践

时间:2014-03-22 12:24:57

标签: unit-testing tdd design-by-contract fuzzing

我有兴趣获得关于如何最好地在实践中使用代码合同和测试的简明建议,从开发到生产全面。我知道两者都是不同的范例,都在测试不同的东西。

在方法级别,合同可以指定参数需要为STRING类型,并且具有要传递的最小长度为三个字符。单元测试可以确保对于与此匹配的任何给定字符串,输出散列是正确的(假设它是函数的角色)。

是否必须进行测试以确保合同失败?我知道,对于有价值的测试,它必须是可重复的,因此不适合协助模糊测试。相反,DbC会允许它。

最初,我认为测试可以简单地确保合同,但我假设这会将合同移到方法定义之外,并且DbC正试图强制实施紧密耦合?

同样,合同是否仅在开发期间积极执行?在生产代码中,构建没有单元测试的迹象,但是DbC呢?合同是“被忽视”还是断言允许在实践中公然失败?

在角色验证的方法中是否存在DbC是真的吗?例如,人们会期望来自前端的无效输入。我假设DbC严格定义在任何输入被假定为“干净”的范围内。

1 个答案:

答案 0 :(得分:1)

我根据您的推理使用DBC和单元测试来处理不同的事情。

我不使用单元测试来验证合同,而是创建一个模拟(模糊)用户行为的“bot”,并使用它来尝试触发我的应用程序中的错误条件。 我发现合同确实非常有用,特别是在我的应用程序输入的排列数量非常大的情况下,因为在这种情况下很难从单元测试中获得信心。

我没有在生产合同的情况下运行我的代码。