行为驱动开发 (BDD) 看起来非常简单。 测试以易于阅读的格式编写，允许来自产品负责人、业务发起人和开发人员的反馈。 这些测试是你团队的实时文档，因此你不需要需求。 这些工具易于使用，并允许你自动化你的测试套件。 每次测试运行都会生成报告，以记录每个步骤并显示测试失败的位置。
快速回顾：易于阅读！ 实时文档！ 自动化！ 报告！ 会有什么问题呢？为什么不是每个人都在这样做？
开始使用 BDD
所以，你准备好开始，并且迫不及待地为你的团队选择合适的开源工具。 你希望它易于使用，自动化所有测试，并为每次测试运行提供易于理解的报告。 很好，让我们开始吧！
但是，别着急……首先，你尝试在你的团队中实施 BDD 的动机是什么？ 如果答案仅仅是自动化测试，那么请随意选择下面列出的任何工具，因为从长远来看，你成功的机会很小。
我的第一次尝试
我管理着一个由业务分析师 (BA) 和质量保证 (QA) 工程师组成的团队，但我的背景是业务分析方面。 大约一年前，我参加了一个讲座，一位开发人员谈到了 BDD 的好处。 他说他和他的团队在上一个项目期间尝试过。 这应该是第一个危险信号，但我当时没有意识到。 你不能简单地选择“尝试 BDD”。 这需要规划、准备和预先考虑你希望你的团队完成什么。
但是，你可以尝试 BDD 的各个部分，而无需大量投资，我最终意识到他和他的团队已经编写了 feature 文件并使用 Cucumber 自动化了这些测试。 我还了解到这是一个完全由团队的开发人员完成的实验，而不是由 BA 或 QA 人员完成的，这违背了理解最终用户行为的目的。
在讲座中，我们被鼓励尝试 BDD，所以我的测试分析师和我去告诉我们的老板，我们愿意尝试一下。 然后，我们不知道该怎么办。 我们没有指导，没有计划，还有一个只想自动化测试的领导团队。 我认为我不需要告诉你这个故事是如何结束的。 实际上，甚至没有结束，只是在最初几次尝试编写行为场景后，缓慢地消失了。
一个全新的开始
快进一年，我来到了一家不同的公司，拥有一支自己的团队，并且脑海中想着 BDD。 我知道那里有价值，但我也知道它比我最初被告知的更深入。 我花了很多时间思考 BDD 如何产生积极影响，不仅对我的团队，而且对我们的整个开发团队。 然后我阅读了 Gaspar Nagy 和 Seb Rose 的探索：使用示例探索行为，我学到的第一件事是，测试自动化是 BDD 的好处，但不应该是主要目标。 难怪我们失败了！
这本书改变了我对 BDD 的看法，并帮助我开始填补我错过的部分。 我们现在正走在（希望是正确的！）在我们的团队中实施 BDD 的道路上。 它涉及我们产品负责人、业务分析师以及手动和自动化测试人员的积极参与，以及我们执行领导层的支持和购买。 我们有一个计划来指导我们的方法和成功的衡量标准。
我们仍在编写需求（永远不要让任何人告诉你这些场景可以完全取代需求！），但我们以更批判的眼光进行编写，并评估需求和测试场景的重叠之处，以及我们如何简化两者。
我已经告诉团队，我们至少两个季度都不能尝试自动化这些测试，到那时我们将进行评估并确定我们是否准备好继续前进。 我们目前的优先事项是定义我们团队的标准语言，练习编写给定/当/然后场景，学习 Gherkin 语法，确定在哪里存储这些测试，以及研究如何将这些测试集成到我们的管道中。
3 个 BDD 工具可供选择
BDD 的核心是一种帮助整个团队了解最终用户的操作和行为的方式，这将导致更清晰的需求、测试，并最终实现更高质量的应用程序。 在选择工具之前，请做好你的预备工作。 考虑你的动机，并理解虽然 BDD 的不同部分和片段相当简单，但将它们集成到你的团队中更具挑战性，需要仔细的思考和计划。 此外，考虑一下你的人员适合在哪里。
每个组织都有不同的角色，BDD 不应仅属于开发人员或测试自动化工程师。 如果你不让业务方面参与进来，你将永远无法获得这种方法的全部好处。 一旦你定义了一个策略并准备好继续自动化你的 BDD 场景，你就可以选择几个开源工具。
Cucumber
Cucumber 可能是最受认可的支持 BDD 的工具。 它被广泛认为是易于学习的简单工具，并且很容易上手。 Cucumber 依赖于以纯文本编写并遵循给定/当/然后格式的测试场景。 每个场景都是一个单独的测试。 场景被分组到 features 中，这类似于测试套件。 场景必须以 Gherkin 语法编写，以便 Cucumber 能够理解和执行场景的步骤。 场景中可读的步骤通过 Cucumber 框架与代码中的步骤定义相关联。 为了成功地编写和自动化场景，你需要业务知识和技术能力的正确组合。 确定你团队中的技能组合，以确定谁将编写和维护场景，以及谁将自动化它们； 最有可能的是，这些应该由不同的角色管理。 由于这些测试是从步骤定义执行的，因此报告非常可靠，可以向你显示测试失败的确切步骤。 Cucumber 可以很好地与各种浏览器和 API 自动化工具配合使用。
JBehave
JBehave 与 Cucumber 非常相似。 场景仍然以给定/当/然后格式编写，并且很容易被整个团队理解。 JBehave 支持 Gherkin，但也有自己的 JBehave 语法可以使用。 Gherkin 更通用，但只要你选择保持一致，任何一种选择都可以使用。 JBehave 比 Cucumber 具有更多的配置选项，并且它的报告虽然非常详细，但需要更多的配置才能从每个步骤获得反馈。 JBehave 是一个强大的工具，但由于它可以更加定制，因此它不如 Cucumber 那么容易上手。 团队需要问问自己，他们究竟需要什么功能，以及学习该工具的各种配置是否值得花费时间。
Gauge
Cucumber 和 JBehave 专门用于与 BDD 一起使用，而 Gauge 则不是。 如果自动化是你的主要目标（而不是整个 BDD 过程），那么值得一看。 Gauge 测试以 Markdown 编写，这使得它们易于阅读。 但是，如果没有更标准的格式，例如给定/当/然后 BDD 场景，测试可能会有很大差异，并且根据作者的不同，某些测试对于业务负责人来说比其他测试更容易理解。 Gauge 可以与多种语言一起使用，因此自动化团队可以利用他们已经使用的语言。 Gauge 还提供带有屏幕截图的报告，以显示测试失败的位置。
你的需求是什么？
实施 BDD 允许团队测试用户的行为。 这可以在不自动化任何测试的情况下完成，但如果正确完成，可以生成一个强大的、可重用的测试套件。 作为一个团队，你将需要准确地确定你的自动化需求是什么，以及你是否真的要使用 BDD，或者你是否更愿意专注于自动化以纯文本编写的测试。 无论哪种方式，你都可以使用开源工具来帮助支持你的测试发展。
评论已关闭。