过去几个月间，互联网上关于测试先行还是测试居后、代码测试比率或者行为驱动开发（BDD）是否真的是测试驱动开发（TDD）的讨论进行得如火如荼。InfoQ就此访问了行为驱动开发（BDD）和测试驱动开发领域知名的专家们，请他们对测试驱动开发（TDD），行为驱动开发（BDD）以及测试比率的运用发表各自的观点。（译注：此后测试驱动开发和行为驱动开发均用简称TDD和BDD代替。）

　　座谈会成员：

　　● J. B. Rainsberg ——顾问及测试驱动专家，关注他的博客：The Code Whisperer

　　● Dan North ——DRW Trading Group的精益技术专员， 行为驱动开发（BDD）的定义者

　　● Gojko Adzic —— 顾问，《Specification by Example》及《Bridging the Communication Gap》作者

　　● Ron Jeffries ——极限编程（XP）及敏捷模式的独立顾问，曾指导过极限编程（XP）的项目

　　● Steve Freeman —— 敏捷讲师及顾问，《Growing Object Oriented Software， Guided by Tests》作者

　　问题：对项目而言，你认为哪些标准会影响你做决定，是采用TDD还是BDD或是什么都不用呢？

　　JB：对这个话题做概述，我觉得有点不合适，莫不如让我来说明下，我在什么时候会用到TDD和BDD，以及这么做的理由吧。

　　我第一次接触TDD是因为我试图寻找一种方法来减少代码中的错误（也叫代码缺陷或Bug）。曾经，我在程序中引入的错误数量让我一度认为自己永远都无法完成编码——不管我怎么努力，都看不到任何希望。我猜测，如果那个时候，能自己测一下代码，就能找到许多简单、愚蠢的代码并自己修复掉。TDD对我来说，并不只是为了不让别人觉得你写的代码有多糟糕，而是避免你错误地认为自己已经完成了编码，却留下一大堆Bug。然而，TDD帮我解决了这个问题，多年之后，我还意识到TDD不仅帮我避免了程序逻辑的错误，更帮我减少了程序设计中的问题。在我运用BDD之后，我发现BDD帮我减少了许多在选择特征与完成特征时的错误。日复一日，我逐渐明白代码的错误不仅让我费时费力，也让我无法按时完成编码工作。这个时候，我开始在项目中贯彻实施TDD与BDD的方法。

　　让我们再回到问题本身，我鼓励大家去思考为什么你们需要做TDD，想想你的理由。不要限于典型的实施TDD与BDD的理由，例如：更好的设计、更少的程序缺陷、更有商业价值的产品特征以及更少的无用功。我鼓励人们多思考一下驱动你这样做的原因，这才是重中之重。我相信你会发现，一旦你采用了这两种方法，必然能按时完成分配的任务，因为这会让你更有条不紊，而不是到后来手忙脚乱。当然，我认为这些理由是因人而异的。

　　Dan：首先允许我给出一些定义。TDD是一种编程技术，它引导程序员思考自己的代码是如何被其他代码所使用，从而避免由代码实现引起的“意外设计”（emergent design）。你首先要写一个测试来描述如何使用下一块代码，然后实现这块代码，并保证它通过测试。这项技术是需要编程技巧的，并且需要考虑何时进行合适的运用（我稍后会展开）。这样做有很多优点，编写测试帮助你理解行业知识并帮助你更好地去命名。一个测试可以发现理解上的差异（“你认为在这个用例中应该怎么做？”），当然，一整套自动测试可以帮助我们发现回归测试中的缺陷。

　　我并不认为我们必须决定是否在这个项目中采用TDD，你几乎可以在任何一个项目中使用TDD。然而，我建议程序员在采用TDD前思考一下，这样做是否有价值。不可否认的是，除了TDD，我们还有其他很多方法可以用来做设计、对某个行业探索和建模以及减少回归测试的风险。有些项目，最有效的方法是逐一采用这些方法，而有些项目不是。不夸张地说，我认为TDD是每个程序员都应该了解，并知道如何去做的、很有用的方法。对于重构，我也持有相同的意见——你必须去了解这个方法，但你需要时间的磨练，去区分何时何地采用这种方法，或转投他法。

　　BDD是一种开发方法，形式类似于极限编程（XP），但不能把它单单看成是TDD的一种实现方式。BDD的作用是把利益关系人、交付团队等不同方面的项目相关人员集中到一起，形成共同的理解，共同的价值观以及共同的期望值。如果你没有碰到过这样的难题，那就可能是哪里出问题了。当然，我也是最近才渐渐地运用起这种方法，之前我都是与较小的团队一起工作，通常也能有比较迅速和通畅的利益关系人反馈。因此，由理解不同而造成影响的情况比较少见。通常，利益关系人会说：“这里你能帮我改一下吗？”或者“这不是我想要的，我来举个例给你。”

　　BDD会从业务目标着手，将这些目标与产品特征和故事衔接起来。BDD提供了如何确定你的验收标准的建议，以及你如何将这些标准落实到决定代码行为的自动测试上。如果你的项目决定采用BDD方法，那就必须从整个项目的层面上来考虑问题（尽管你可以在子项目中运用BDD），而且必须拉上整个团队一起做。

　　我赞成以下说法：只要能够提交合格的代码，那么每个程序员或配对编程的人员就都有权利以他们所偏好的方式交付软件。如果他们打算使用TDD，我们就应该支持他们这样做。如果他们打算做些其他的，只要团队成员没有问题，我们也可以允许。