language-agnostic - 契约(Contract)设计和测试驱动开发

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

已关闭 4 年前。

Improve this question

我正在努力改进我们团队的开发流程，并且正在考虑如何最好地实现契约(Contract)设计和测试驱动开发。看来这两种技术有很多重叠，我想知道是否有人对以下(相关)问题有一些见解:

• 除非您使用某种代码生成器来生成基于契约的单元测试，否则使用 TDD 和 DbC 是否违反 DRY 原则？否则，您必须在两个地方维护契约(Contract)(测试和契约(Contract)本身)，还是我遗漏了一些东西？
• TDD 在多大程度上使 DbC 变得多余？如果我把测试写得足够好，那不就相当于写了一份契约(Contract)吗？如果我在运行时以及通过测试执行契约(Contract)，我是否只能获得额外的好处？
• 仅使用 TDD 比 TDD 与 DbC 结合使用是否更容易/更灵活？

这些问题的要点是这个更普遍的问题:如果我们已经正确执行 TDD，如果我们还使用 DbC，我们是否会在开销方面获得显着的好处？

一些细节，尽管我认为这个问题很大程度上与语言无关:

• 我们的团队很小，<10 名程序员。
• 我们主要使用 Perl。

Answer 1

注意差异。

设计由契约(Contract)驱动。契约(Contract)驱动的设计。

开发由测试驱动。测试驱动开发。

它们之间的相关性在于，一个先于另一个。它们描述了不同抽象级别的软件。

您在实现时会放弃设计吗？您认为设计文档违反了 DRY 吗？你们分别维护合约和代码吗？

软件是契约(Contract)的一种实现。测试是另一回事。用户手册是第三个。操作指南是第四个。数据库备份/恢复过程是契约(Contract)实现的一部分。

我看不到“按契约(Contract)设计”的任何开销。

• 如果您已经在进行设计，那么您可以将格式从过多的文字更改为正确的文字来概述契约(Contract)关系。

• 如果您不进行设计，那么签订契约(Contract)可以消除问题，降低成本和复杂性。

我看不出灵 active 有任何损失。

1. 从契约(Contract)开始，

2. 然后

   a.编写测试并

   b.写代码。

了解这两项开发事件本质上是如何交织在一起的，并且都来自契约(Contract)。