你可能认为这个问题是像StackOverflow上提出的
this问题。但我试图看看不同的东西。
在TDD中，我们编写包括不同条件，标准，验证码的测试。如果一个类通过所有这些测试，我们很好去。它是一种确保类实际上做它应该做什么和没有别的方法。
如果你遵循Bertrand Meyers的书面对象软件构建一个字，该类本身有内部和外部合同，以便它只做它应该做什么，没有其他，没有外部测试所需的，因为代码，以确保合同遵循是类的一部分。
快速示例，使事情清楚 –
TDD-
- Create test to ensure that in all cases a value ranges from
(0-100)- Create class containing method that passes the test.
DBC-
- Create a class,create a contract for that member var to range from
(0-100),set contract for contract
breach,define method.
我个人喜欢DBC。
有没有理由为什么纯DBC不那么受欢迎？它是语言或工具，还是敏捷，还是只是我喜欢让代码负责自己？
如果你认为我不是正确的，我会更愿意学习。
DBC的主要问题是，在绝大多数情况下，无法正式指定合同(至少不方便)，或者不能使用当前的静态分析工具检查。直到我们超越主流语言(不是埃菲尔)的这一点，DBC不会给予人们需要的那种保证。
原文链接：https://www.f2er.com/javaschema/282475.html在TDD中，测试是由人基于方法的当前自然文本规范来编写的(希望有的)。因此，人类通过写测试来解释正确性，并基于该解释获得某种保证。
如果你阅读Sun的JavaDocs指南，它说文档应该基本上写出一个足以编写测试计划的合同。因此，合同设计不一定与TDD相互排斥。
