我正在改进我们小组的开发过程，我正在考虑如何最好地实施与测试驱动开发的合同设计。看来这两种技术有很多重叠，我想知道是否有人对以下(相关)问题有一些洞察力：
>除了你使用某种类型的代码生成器生成基于合同的单元测试，是不是违反DRY原则有TDD和DbC？否则，你必须在两个地方(测试和合同本身)保持合同，或者我缺少一些东西？
> TDD在多大程度上使DbC冗余？如果我写的测试足够好，不是他们等同于写一份合同吗？如果我在运行时以及通过测试执行合同，我只能获得额外的好处吗？
>它是明显更容易/更灵活的只使用TDD而不是TDD与DbC？
这些问题的主要问题是这个更一般的问题：如果我们已经正确地做TDD，如果我们也使用DbC，我们会得到显着的收益吗？
几个细节，虽然我认为这个问题在很大程度上是语言无关的：
>我们的团队非常小，< 10个程序员。
>我们主要使用Perl。
注意差异。
设计由合同驱动。合同驱动设计。
开发由测试驱动。测试驱动开发。
他们是相关的，一个在另一个之前。他们描述了不同抽象层次的软件。
当你去实施时，你放弃设计吗？你认为设计文档是否违反DRY？你单独维护合同和代码吗？
软件是合同的一个实施。测试是另一个。用户手册是第三个。操作指南是第四。数据库备份/恢复过程是合同实施的一部分。
我看不到合同设计的任何开销。
>如果你已经在做设计，那么你将格式从太多的单词改为只是正确的单词，以概述合同关系。
>如果你不在做设计，那么编写合同将消除问题，降低成本和复杂性。
我看不到任何灵活性的损失。
>开始合同，
>然后
一个。写测试和
b。写代码。
看看两个发展活动是如何交织在一起的，两者都来自合同。
