单元测试 – 与测试驱动开发相比,为什么按合同设计不那么受欢迎？

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

在TDD中,我们编写包含不同条件,标准,验证码的测试.如果一个班级通过了所有这些测试,我们就可以了.这是一种确保班级实际上做了它应该做的事情的方式,而不是别的.

如果你按照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不那么受欢迎？它是语言或工具还是敏捷,还是我喜欢让代码对自己负责？

如果你认为我思考不对,我会更愿意学习.

DBC的主要问题是,在绝大多数情况下,合同无法正式指定(至少不方便),或者无法使用当前的静态分析工具进行检查.在我们超越主流语言(不是eiffel)的这一点之前,DBC不会给出人们需要的那种保证.

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

如果您阅读Sun编写JavaDocs的指南,它说文档应该基本上制定一份足以编写测试计划的合同.因此,合同设计不一定与TDD互斥.