unit-testing - 与测试驱动开发相比，为什么按契约(Contract)设计不那么流行？

Question

你可能认为这个问题就像 this之前在 StackOverflow 上提出的问题。但我试图以不同的方式看待事物。

在 TDD 中，我们编写包含不同条件、标准、验证码的测试。如果一个类(class)通过了所有这些测试，我们就可以开始了。这是确保该类确实完成其应做的事情而不是其他任何事情的一种方法。

如果你逐字遵循Bertrand Meyers的书面向对象的软件构建，类本身具有内部和外部契约，因此它只做它应该做的事情只做任何事情。不需要外部测试，因为确保遵循契约的代码是类的一部分。

简单的例子让事情变得清晰

TDD

1. Create test to ensure that in all cases a value ranges from (0-100)

2. Create a class containing a 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 a method.

我个人喜欢 DBC 方法。

<小时/>

纯DBC不那么受欢迎有什么原因吗？是语言、工具还是敏捷，还是只是我喜欢让代码对自己负责？

如果你认为我的想法不对，我非常愿意学习。

Answer 1

DBC的主要问题在于，在绝大多数情况下，合约要么无法被正式指定(至少不方便)，要么无法用现有的静态分析工具进行检查。在主流语言(不是 Eiffel)突破这一点之前，DBC 不会提供人们需要的那种保证。

在 TDD 中，测试是由人类根据方法的当前自然文本规范编写的，(希望)有详细记录。因此，人类通过编写测试来解释正确性，并根据该解释获得一些保证。

如果您阅读 Sun 编写 JavaDocs 的指南，它会说文档应该本质上列出足以编写测试计划的契约(Contract)。因此，契约设计不一定与 TDD 相互排斥。