按合同设计 (DbC) 和测试驱动开发的最佳实践 [关闭]

Question

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

在方法级别，合约可以指定参数必须是 STRING 类型，并且要传递的最小长度为三个字符。单元测试可以确保对于任何与此匹配的给定字符串，输出哈希是正确的（假设这是函数的角色）。

是否必须存在测试以确保合同失败？我知道，要使测试有价值，它必须是可重复的，因此不是协助模糊测试的好人选。相反，DbC 会允许这样做。

最初，我认为测试可以简单地确保合同，但我假设这会将合同移到方法定义之外，并且 DbC 正在尝试强制执行紧密耦合？

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

说 DbC 不存在于以验证为角色的方法中是真的吗？例如，人们会期望来自前端的无效输入。我假设 DbC 是在任何输入都被假定为“干净”的领域内严格定义的。

Answer 1

按照您的推理，我将 DBC 和单元测试用于不同的事物。

我不使用单元测试来验证合约，而是创建一个模拟（模糊）用户行为的“机器人”，并使用它来尝试在我的应用中触发错误条件。 我发现合约非常有用，尤其是在我的应用程序输入的排列数量非常大的情况下，因为在这种情况下很难仅从单元测试中获得信心。

我不在启用合同的生产环境中运行我的代码。