为什么与测试驱动的开发相比，按合同设计不那么受欢迎? [英] Why is design-by-contract not so popular compared to test-driven development?

问题描述

您可能会认为这个问题就像此问题StackOverflow较早.但是我试图以不同的方式看待事情.

You may think this question is like this question asked on StackOverflow earlier. But I am trying to look at things differently.

在TDD中，我们编写的测试包括不同的条件，标准和验证码.如果一个班级通过所有这些测试，我们将很高兴.这是确保类实际完成了应做的事情的一种方式.

In TDD, we write tests that include different conditions, criteria, verification code. If a class passes all these tests we are good to go. It is a way of making sure that the class actually does what it's supposed to do and nothing else.

如果您逐字遵循 Bertrand Meyers 的《 面向对象的软件构造》 一书，则该类本身具有内部和外部契约，因此它只能执行其应有的功能做，别无其他.不需要进行外部测试，因为该类的一部分是确保遵循合同的to代码.

If you follow Bertrand Meyers' book Object Oriented Software Construction word by word, the class itself has internal and external contracts, so that it only does what its supposed to do and nothing else. No external tests required because the to code to ensure contract is followed is the part of the class.

简单明了的例子

TDD

1. 创建测试以确保在所有情况下该值的范围都在(0-100)

1. 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

1. 创建一个类，为该成员var创建一个范围为(0-100)的合同，设置违反合同的合同，定义一个方法.

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方法.

I personally like the DBC approach.

纯DBC为何不那么受欢迎?是语言或工具，还是敏捷?还是只喜欢由我自己负责的代码的我?

Is there a reason why pure DBC is not so popular? Is it the languages or tools or being Agile or is it just me who likes to have code responsible for itself?

如果您认为我的想法不对，那么我会乐于学习.

If you think I am not thinking right, I would be more than willing to learn.

推荐答案

DBC的主要问题在于，在大多数情况下，不能正式指定合同(至少不方便)，或者无法检查合同使用当前的静态分析工具.除非我们对主流语言(不是Eiffel)有所了解，否则DBC不会提供人们需要的那种保证.

The main problem with DBC is that in the vast majority of cases, either the contract cannot be formally specified (at least not conveniently), or it cannot be checked with current static analysis tool. Until we get past this point for mainstream languages (not Eiffel), DBC will not give the kind of assurance that people need.

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

In TDD, tests are written by a human being based on the current natural-text specifications of the method that are (hopefully) well-documented. Thus, a human interprets correctness by writing the test and gets some assurance based on that interpretation.

如果您阅读Sun的JavaDocs编写指南，它说该文档实质上应该列出足以编写测试计划的合同.因此，合同设计不一定与TDD互斥.

If you read Sun's guide for writing JavaDocs, it says that the documentation should essentially lay out a contract sufficient to write a test plan. Hence, design by contract is not necessarily mutually exclusive with TDD.

这篇关于为什么与测试驱动的开发相比，按合同设计不那么受欢迎?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！