合同设计和测试驱动开发 [英] Design By Contract and Test-Driven Development
问题描述
我正在努力改善小组的开发流程，并且正在考虑如何最好地实现按合同进行设计"和测试驱动开发".似乎这两种技术有很多重叠之处，我想知道是否有人对以下(相关)问题有所了解:
I'm working on improving our group's development process, and I'm considering how best to implement Design By Contract with Test-Driven Development. It seems the two techniques have a lot of overlap, and I was wondering if anyone had some insight on the following (related) questions:
- 除非您使用某种代码生成器基于合同生成单元测试，否则拥有TDD和DbC是否违反DRY原则?否则，您必须在两个地方维护合同(测试和合同本身)，还是我遗漏了一些东西?
- TDD使DbC冗余到什么程度?如果我写的测试足够好，那不等于写合同吗?如果我在运行时以及通过测试执行合同，是否只能获得额外的利益?
- 仅使用TDD而不使用带有DbC的TDD是否明显更容易/更灵活?
这些问题的重点是一个更笼统的问题:如果我们已经在正确地进行TDD，那么如果我们也使用DbC，我们会在开销方面获得重大收益吗?
The main point of these questions is this more general question: If we're already doing TDD properly, will we get a significant benefit for the overhead if we also use DbC?
一些细节，尽管我认为这个问题在很大程度上与语言无关:
A couple of details, though I think the question is largely language-agnostic:
- 我们的团队很小，只有不到10名程序员.
- 我们主要使用Perl.
推荐答案
请注意区别.
设计受合同约束.合同驱动的 Design .
Design driven by contract. Contract Driven Design.
Develop 由测试驱动.测试驱动的开发.
Develop driven by test. Test Driven Development.
它们之间的关系是，一个在另一个之前.他们描述了处于不同抽象级别的软件.
They are related in that one precedes the other. They describe software at different levels of abstraction.
进行实施时会丢弃设计吗?您是否认为设计文件违反了DRY?您是否分别维护合同和代码?
Do you discard the design when you go to implementation? Do you consider that a design document is a violation of DRY? Do you maintain the contract and the code separately?
软件是合同的一种实施.测试是另一回事.用户手册是第三本.操作指南是第四.数据库备份/还原过程是合同实施的一部分.
Software is one implementation of the contract. Tests are another. User's manual is a third. Operations guide is a fourth. Database backup/restore procedures are one part of an implementation of the contract.
我看不到Design by Contract的任何间接费用.
I can't see any overhead from Design by Contract.
-
如果您已经在进行设计，则可以将格式从太多的单词更改为恰好合适的单词以概述合同关系.
If you're already doing design, then you change the format from too many words to just the right words to outline the contractual relationship.
如果您不进行设计，那么签订合同将消除问题，降低成本和复杂性.
If you're not doing design, then writing a contract will eliminate problems, reducing cost and complexity.
我看不到任何灵活性的损失.
I can't see any loss of flexibility.
-
以合同开头
start with a contract,
然后
a.编写测试和
b.编写代码.
看看这两个开发活动是如何本质上交织在一起的，并且都来自合同.
See how the two development activities are essentially intertwined and both come from the contract.
这篇关于合同设计和测试驱动开发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
