你可能认为这个问题就像之前在StackOverflow上提出的
this问题一样.但我试图以不同的方式看待事物.
在TDD中,我们编写包含不同条件,标准,验证码的测试.如果一个班级通过了所有这些测试,我们就可以了.这是一种确保班级实际上做了它应该做的事情的方式,而不是别的.
如果你按照Bertrand Meyers的书中逐字逐句地介绍面向对象的软件构建,那么这个类本身就有内部和外部的契约,所以它只能做它应该做的事情,而不是别的.不需要进行外部测试,因为确保合同的代码是类的一部分.
快速举例说明事情
TDD
Create test to ensure that in all cases a value ranges from (0-100)
Create a class containing a method that passes the test.
DBC
- Create a class,create a contract for that member
varto range from (0-100),set contract for contract breach,define a method.
我个人喜欢DBC方法.
有没有理由说纯DBC不那么受欢迎？它是语言或工具还是敏捷,还是我喜欢让代码对自己负责？
如果你认为我思考不对,我会更愿意学习.
DBC的主要问题是,在绝大多数情况下,合同无法正式指定(至少不方便),或者无法使用当前的静态分析工具进行检查.在我们超越主流语言(不是Eiffel)的这一点之前,DBC不会给出人们需要的那种保证.
原文链接：https://www.f2er.com/javaschema/282067.html在TDD中,测试是由人类根据当前的方法自然文本规范编写的(希望)有充分的文档记录.因此,人类通过编写测试来解释正确性,并基于该解释获得一些保证.
如果您阅读Sun编写JavaDocs的指南,它说文档应该基本上制定一份足以编写测试计划的合同.因此,合同设计不一定与TDD互斥.
