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

我对如何在实践中最好地使用代码契约和测试,从开发到生产,获得一个简明的建议很感兴趣。我知道两者都是不同的范式,都在测试不同的东西。

在方法级别上,契约可能会指定参数类型。参数类型必须为STRING,并且要通过的最小长度为三个字符。单元测试可能会确保对于与此匹配的任何给定字符串,输出哈希值都是正确的(假设是函数的角色)。

必须存在测试以确保合同失败吗?我明白,要使测试有价值,它必须是可重复的,因此不适合辅助模糊化。相反,DbC会允许它。

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

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

DbC不存在于其作用是验证的方法中,这是真的吗?例如,可以预期来自前端的无效输入。我假设DbC严格定义在任何输入都假定为“干净”的领域内。