本节书摘来自异步社区《Cucumber：行为驱动开发指南》一书中的第1章，第1.1节，作者：【英】Matt Wynne , 【挪】Aslak Hellesy著，更多章节内容可以访问云栖社区“异步社区”公众号查看

第1章　为何使用Cucumber

软件始于一个想法。

我们假设这是一个优秀的想法——一个能让世界变得更加美好，或者至少能让一些人赚到一些钱的想法。而软件开发人员所面临的挑战就是要落实这个想法，使其能真正产生效益。

最初的想法是完美、漂亮的。如果拥有该想法的人碰巧是一个天才软件开发人员，那事情就非常简单了：他无须向任何人解释就能直接把想法实现成可工作的软件。然而更常见的情况是，拥有最初想法的人并不具备使其想法变为现实所必需的编程技能，因此这个想法必须从他的脑中传递到另外一些人的脑中。也就是说，相关的人需要沟通想法。

大部分软件项目会涉及多人紧密协作的团队，高质量的沟通对项目的成功至关重要。你可能已经知道，高质量的沟通并不仅仅是口若悬河地把你的想法描述给他人，你还需要收集可靠的反馈以确保对方正确理解了你的意思。这就是敏捷软件团队要用小型增量的方式开发软件的原因，采用增量方式开发出的软件可用来收集反馈，询问利益相关人：“是这个意思吗？”

但这仍然不够。如果开发人员误解了一个想法，然后花了两周的一次迭代实现了它，那么他不仅浪费了两周的时间，还因为引入了没有正确反映最初想法的概念和功能而破坏了代码的完整性。其他开发人员可能已经开始在这些错误想法的基础上不经意添加了更多代码，使它们基本上不可能完全从代码中消失。

我们需要一种过滤器，让我们的代码远离这些被误解的想法。

1.1　自动化验收测试

Cucumber：行为驱动开发指南

不是让业务人员直接将需求交给开发团队，然后也没什么反馈的机会，而是让开发团队和业务人员合作编写自动化测试来表述业务人员想要的结果。我们称之为验收测试，因为这类测试表述了软件需要做什么才能让业务人员觉得软件可以被验收。验收测试写好的时候，运行它们肯定会得到失败的结果，因为实现代码还不存在，但验收测试抓住了业务人员真正关心的东西，并且让所有人明确了完成软件需要做哪些事情。

验收测试和单元测试不同，单元测试针对的是开发人员，帮助他们启动并验证软件设计。有一种说法是，单元测试确保你正确地编写软件，而验收测试则确保你编写正确的软件。

自动化验收测试作为一项既定实践已在很多XP团队中沿用多年，然而，许多经验不那么丰富的敏捷团队似乎把TDD看作仅仅针对程序员的实践。正如Lisa Crispin和Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》一书[CG08]中指出的那样，如果没有面向业务的自动化验收测试，程序员很难知道他们需要编写怎样的单元测试。自动化验收测试可以帮助团队关注重点，确保每次迭代你所做的都是你所能做的最有价值的工作。当然你仍然会犯错——但犯错的概率大大降低了，这意味着你可以准点到家，享受业余生活。