单元测试 – 合同设计与测试驱动开发？

你可能认为这个问题是像StackOverflow上提出的 this问题。但我试图看看不同的东西。

在TDD中，我们编写包括不同条件，标准，验证码的测试。如果一个类通过所有这些测试，我们很好去。它是一种确保类实际上做它应该做什么和没有别的方法。

如果你遵循Bertrand Meyers的书面对象软件构建一个字，该类本身有内部和外部合同，以便它只做它应该做什么，没有其他，没有外部测试所需的，因为代码，以确保合同遵循是类的一部分。

快速示例，使事情清楚 –

TDD-

1. Create test to ensure that in all cases a value ranges from
   (0-100)
2. Create class containing method that passes the test.

DBC-

1. 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不会给予人们需要的那种保证。

在TDD中，测试是由人基于方法的当前自然文本规范来编写的(希望有的)。因此，人类通过写测试来解释正确性，并基于该解释获得某种保证。

如果你阅读Sun的JavaDocs指南，它说文档应该基本上写出一个足以编写测试计划的合同。因此，合同设计不一定与TDD相互排斥。