开源开发工具_3个开源行为驱动的开发工具

开源开发工具

行为驱动开发 （BDD）似乎非常容易。 测试以易于阅读的格式编写，允许产品所有者，业务赞助商和开发人员提供反馈。 这些测试是您团队的有效文档，因此您不需要任何要求。 这些工具易于使用，可让您自动化测试套件。 每次测试运行都会生成报告，以记录每个步骤，并向您显示测试失败的地方。

快速回顾：易于阅读！ 生活文件！ 自动化！ 报告！ 可能出什么问题了，为什么每个人都没有这样做？

BDD入门

因此，您已经准备就绪，可以迫不及待地为团队选择合适的开源工具。 您希望它易于使用，自动化所有测试并为每次测试运行提供易于理解的报告。 太好了，让我们开始吧！

除外，不是那么快……首先，您尝试在团队中实施BDD的动机是什么？ 如果答案仅是使测试自动化，请继续并选择下面列出的任何工具，因为从长远来看，您将看到最小的成功。

我的第一努力

我管理着一个业务分析人员（BA）和质量保证（QA）工程师团队，但我的背景是业务分析方面。 大约一年前，我参加了一个演讲，其中一个开发人员讨论了BDD的好处。 他说，他和他的团队在上一个项目中进行了尝试。 那应该是第一个危险信号，但当时我还没有意识到。 您不能简单地选择“尝​​试一下BDD”。 它需要计划，准备和周密考虑您希望团队完成的工作。

但是，您无需花费大量投资就可以尝试BDD的各个部分，我最终意识到他和他的团队已经编写了功能文件并使用Cucumber自动化了这些测试。 我还了解到，这是仅由团队的开发人员而不是BA或QA员工进行的实验，这违背了理解最终用户行为的目的。

在谈话中，我们被鼓励尝试BDD，因此我和我的测试分析师去找老板，说我们愿意试一试。 然后，我们不知道该怎么办。 我们没有指导，没有适当的计划，而领导团队只是想自动化测试。 我认为我不需要告诉你这个故事是如何结束的。 实际上，甚至没有尽头，只是在最初尝试编写行为场景之后进行了一次缓慢的尝试。

一个新的开始

快进了一年，我在另一家公司，拥有自己的团队和BDD。 我知道那里有价值，但是我也知道它的价值比我最初出售的价值还要深。 我花了很多时间思考BDD如何对我们的团队以及整个开发团队产生积极的影响。 然后，我读了Gaspar Nagy和Seb Rose的《 发现：使用示例探索行为》 ，我学到的第一件事是测试自动化是BDD的一项优势，但它不应成为主要目标。 难怪我们失败了！

这本书改变了我对BDD的看法，并帮助我开始填写我所缺少的部分。 我们现在（希望是正确的！）在我们的团队中实施BDD。 它涉及产品所有者，业务分析人员以及手动和自动测试人员的积极参与，以及执行领导层的支持和支持。 我们为我们的方法和成功措施制定了计划。

我们仍在编写需求（永远不要让任何人告诉您这些场景可以完全替代需求！），但是我们正以更加严格的眼光来评估这样做，并评估需求和测试场景的重叠之处以及我们如何精简两者。

我已经告诉团队，我们甚至不能尝试至少在两个季度内使这些测试自动化，此时我们将评估并确定我们是否准备好前进。 我们当前的工作重点是定义团队的标准语言，练习编写给定/何时/然后的场景，学习Gherkin语法，确定将这些测试存储在何处以及研究如何将这些测试集成到我们的管道中。

3种BDD工具可供选择

BDD的核心是一种帮助整个团队了解最终用户的行为和行为的方式，这将导致更清晰的需求，测试以及最终更高质量的应用程序。 在选择工具之前，请先做准备。 考虑一下您的动机，并理解，尽管BDD的各个部分相当简单，但将它们集成到您的团队中却更具挑战性，需要仔细考虑和计划。 此外，请考虑您的员工适合的位置。

每个组织都有不同的角色，BDD不应仅属于开发人员，也不应该属于测试自动化工程师。 如果您不涉及业务方面，那么您将永远无法获得这种方法的全部好处。 定义好策略并准备好实现BDD方案自动化后，便有几种开源工具供您选择。

Cucumber

Cucumber可能是最受支持的BDD工具。 它被广泛认为是一种简单易学的工具，易于上手。 Cucumber依赖以纯文本编写并遵循给定/何时/然后格式的测试方案。 每个方案都是一个单独的测试。 场景被分组为功能，与测试套件相当。 必须使用Gherkin语法编写方案，Cucumber才能理解和执行方案的步骤。 场景中易于理解的步骤通过Cucumber框架与代码中的步骤定义相关联。 为了成功编写和自动化方案，您需要正确组合业务知识和技术能力。 确定您团队的技能，以确定谁来编写和维护方案以及谁将它们自动化； 这些很可能应该由不同的角色来管理。 由于这些测试是根据步骤定义执行的，因此报告非常可靠，可以向您显示测试在哪一步上失败了。 Cucumber可以与各种浏览器和API自动化工具很好地配合使用。

杰贝夫

JBehave与Cucumber非常相似。 场景仍然以给定/何时/然后的格式编写，并且整个团队都很容易理解。 JBehave支持Gherkin，但也有自己的JBehave语法可以使用。 小Cucumber更为通用，但是只要您选择一致，任一种选择都将起作用。 JBehave比Cucumber具有更多的配置选项，并且其报告尽管非常详细，但需要更多的配置才能从每个步骤获得反馈。 JBehave是一个功能强大的工具，但是由于它可以进行更多的自定义，因此入门起来并不容易。 团队需要确切地问自己，他们需要什么功能以及学习工具的各种配置是否值得花费时间。

测量

在专门设计Cucumber和JBehave与BDD一起使用的情况下， Gauge不是。 如果自动化是您的主要目标（而不是整个BDD流程），那么值得一看。 量规测试是用Markdown编写的，因此易于阅读。 但是，如果没有更标准的格式（例如给定的/何时/然后是 BDD场景），则测试的范围可能会大不相同，并且根据作者的不同，某些测试对于企业主而言比其他测试容易消化得多。 标尺可以使用多种语言，因此自动化团队可以利用他们已经使用的语言。 仪表还提供带有屏幕截图的报告，以显示测试失败的地方。

你有什么需要

实施BDD可使团队测试用户的行为。 可以完全不自动执行任何测试来完成此操作，但是如果正确完成操作，则可以生成功能强大且可重复使用的测试套件。 作为一个团队，您将需要准确确定自动化需求是什么，是否真正使用BDD还是要专注于自动化以纯文本编写的测试。 无论哪种方式，都可以使用开源工具来帮助您支持测试的发展。

---

接下来要读什么

翻译自: https://opensource.com/article/19/2/behavior-driven-development-tools

开源开发工具