转载

测试驱动开发与行为驱动开发中的测试先行方法

Gil Zilberfeld将在 Agile Practitioners会议上举办小型研讨会，讨论测试先行（test first）方法，测试驱动开发（TDD）和行为驱动开发（BDD）的基础。

Test-First是一个很优秀的工具。它能促进团队内更好的理解力和生产力。其结果是高质量的代码——无论是早期成功发现 bug还是正确实现特性方面。

Agile Practitioners 2016会议将于1月26-27日在以色列特拉维夫举行，InfoQ将会覆盖本次会议的新闻，Q&As和文章。

（……）今年我们的主题是亲身实践敏捷。我们知道没有老师能够传授亲身体验，因此我们举办了很多研讨会和实用讲座，会议参加者可以亲身体验、听到和看到敏捷活动是如何在许多成功企业内实施的。

InfoQ采访了 Zilberfeld，关于测试先行方法的优势，测试驱动开发和行为驱动开发概念，团队使用 BDD和 TDD的实例，以及如何在不编写任何代码的情况下探索 BDD和 TDD。

InfoQ：“测试先行”方法的优势是什么？

Zilberfeld：测试驱动开发是从90年代末的极限编程从业者开始的。但事实上，人们在编写代码的数十年前已经开始编写测试了。

其理念是这样的：当程序员编写代码时，他们通常在代码中解决复杂问题。但是，这种方式常常使得结果同样复杂，并且含有远远超过实际需要解决的问题（假设重要的东西已经被编码）。

这意味着需要测试更多的代码。测试有时需要改变“已经工作”的代码，这会引入风险。最终导致要么根本没有进行测试，因为没有时间测试，或者是次优的测试，因为无法覆盖我们想要覆盖的范围。

测试先行定义了工作需求。因为我们有测试形式的定义，它定义了为了解决具体问题我们需要编写什么样的代码。仅仅通过运行测试就可以非常简单地知道我们是否有可工作的功能。

这种方式会扩大测试覆盖率，因为测试成为优先开发活动，而不会被迫推到最后。

另外，编写这些测试和制定场景的时候，我们会更深入地探索问题空间，因为会出现许多问题。而在事后测试（test after）中，有时不会发生这些讨论，开发人员以他们的思维编码，而不是以解决方案的需求编码。

InfoQ：你能简单介绍一下行为驱动开发（BDD）和测试驱动开发（TDD）的概念吗？

Zilberfeld：在 TDD和 BDD中，你先将问题分解成多个情境，也就是例子。我们的头脑更容易专注小情境，而不善于解决大的、复杂的问题。

然后开始著名的红-绿-重构循环，就像这样：

编写一个失败的情境。失败是因为编译或者因为代码不存在。无论如何，该测试是代码如何被外部模块使用的案例。
努力让测试通过。重点是可工作的功能而不是形式，也就是编写最小的实现，让它通过测试。更进一步，它应该通过迄今为止我们编写的整个测试套件。
改进代码。现在一切都是绿色的，使用测试安全网我们可以重写代码。如果我们破坏了什么，我们会立即知道。

将问题分解成更小的部分，然后以增量的形式开发需要的代码，并且在流程中加入急需的刹车。这有助于我们思考我们遗漏的情境，而不是“我们知道解决方案是什么样子”。

BDD开始于2000年代中期，更进一步地将 TDD推向产品空间。通过使用产品用途案例，我们可以仅仅开发情境所需的代码。我们可以专注对业务重要的情境。然后可以使用 TDD编写实际代码。

BDD最大的优势是沟通。如果你将“三个同伴”——业务分析师、开发人员和测试人员——集中到一个房间，讨论我们希望看到的行为案例，那么在编写代码之前，我们将会得到最好的提出和解决问题的观点。

而这就是 BDD——讨论商定的行为案例。这些案例可以写成自动化测试（但这不是要求），然后编码使测试通过，最后重构代码。

显然，BDD情境的详细程度比更精细的 TDD测试还要宽泛。尽管我发现在某些方面它们是相互关联的，但是在 TDD和 BDD情境中编写测试还是需要不同的技能。

InfoQ：你有与合作团队使用 BDD和 TDD的案例吗？

Zilberfeld：在 BDD中，由谁编写情境是有区别的，但是我合作的大多数团队中，都是测试人员编写情境。这些案例的讨论通常在编写代码之前。测试人员和开发人员并行工作——测试人员专注高水平的自动化测试，开发人员专注代码和单元测试（测试优先与否）。一旦完成就会对情境进行评审。然后在某个时候对开发和测试进行集成，以确保测试通过。

BDD和 TDD在迭代中非常“敏捷”，这使得情境“完成”与否非常的明显。BDD情境要么“符合”迭代，要么就是故事过于冗长。

在实现上 TDD稍有不同。培训之后，开发人员会对等待他们的代码妥协。通常这些都是遗留代码，这与干净的测试先行代码不同。

我常开玩笑说 TDD中最后一个 D是纪律。因为它对测试先行的实现最重要。它与我们被教导的不同也更难，因此在看到价值之前我们需要团队的支持。这就是为什么大部分团队最终不做 TDD，勉强接受事后测试的缘故。

熬过困难的前期之后，开始清理自己的代码，添加更多的覆盖率。代码变得更加容易维护。并且从社会角度来看，新加入团队的开发人员会带着“这就是我们的工作方式”理念加入 TDD。这是一个正面的反馈循环。

InfoQ：你能给 InfoQ读者提前透露一下 Agile Practitioners会议上研讨会的内容吗？以及向参会者展示如何在不编写任何代码的情况下探索 BDD和 TDD？

Zilberfeld：这次研讨会背后还有一个故事。几年前，我打算在比利时 Testing Days会议上举办“TDD a spaceship”研讨会（我打算三月在荷兰的 Agile Testing Days会议上举办）。它是为开发人员设计的，但是参与者都是测试人员，拥有极少的编码经验。因此研讨会变成解释测试先行的理念，并且是在没有实际编码的情况下。很自然地，我被吸引到星球大战的例子，我们交谈、做课堂笔记，并讨论了验收标准，以及如何知道故事已经完成。

那次研讨会之后，我考虑如何以一种经验的方式实现它。碰巧，我被介绍给GIF制作软件工具，突然之间我们有了能够帮助的工具。这是一个创建型工具，人们可以提前写电影“脚本”，构建并运行，并能够立即获得反馈。

很棒的是我们可以应用敏捷开发原则和经验。因为你所想象的电影样式跟实际结果总是会有出入，所以我们构建了一个新的版本。

另一个案例是处理遗留代码。其中一个练习是在电影中更换演员，但是因为电影已经编辑，因此我们只能在开头或者结尾添加场景。鉴于需求与代码不能分开考虑，如何更改需求与已经构建完成的代码之间的冲突这一理念就非常有启发性。