Tie/Wrap任何测试工具的BDD框架

Question

除了测试步骤的自然语言方面之外，将bdd(行为开发设计)框架封装在专有测试工具周围还有什么额外的好处呢？

对于可以简化bdd与测试工具/工具集成的工具，有什么建议吗？

Answer 1

我觉得其中一些额外的好处是：

1. 测试工具与测试工具之间的隔离。我的意思是，只有在web浏览器上执行操作时才会调用测试工具。
2. 自然分页，除前一步外，将当前步骤放置到适当的页面上下文中。
3. 用自然英语句子进行更好的报告。
4. 分层/结构化的测试方法允许更好的调试，因为有一个更窄的视图。因此，步骤失败可以追溯到操作，而不是在整个操作脚本中导航。

关于一个工具，我编写了以下内容，它允许黄瓜-js通过驱动程序与任何测试工具集成:在nodejs平台上的wrap。到目前为止，只有作为示例实现的驱动程序用于测试完成和测试执行工具。

https://github.com/vsashidh/generator-wrap-bdd：安装程序

https://github.com/vsashidh/wrapping-BDD：main

Answer 2

黄瓜!

主要的好处是使用业务域术语用用户语言编写的测试。

这有助于将开发人员和用户聚集在一起，更好地理解和实现应用程序。

对于某些方面，程序员会欣赏产品所有者非常具体，并以一种逻辑的方式记录规范和需求。对于其他方面，产品所有者将感激能够理解已经实现的功能，基于他们可以阅读的简单英语测试。在其他情况下，程序员会更多地意识到微妙的现实因素，这些因素会极大地影响设计和实现。

这个框架的一个实际例子是Cucumber，它是一个围绕RSpec的包装器，但可以并且已经与许多其他开发框架和语言一起使用。

Answer 3

行为成为定义的

如果每个人都参与了这个过程，而不是一个需求列表，那么每个人都会得到一个行为列表，然后定义需求。当过程被更多地使用，并且讨论变得更加彻底，需求从它们变得清晰的定义。

测试用例更容易

当正确使用BDD框架时，测试用例对每个人都更容易。通过以人类可读的格式查看测试用例失败时所做的事情，您就可以确定进一步的操作和发现过程来确定任何其他问题。

跟随模式

软件开发往往有缺陷的模式。如果您的BDD框架有历史数据，它将允许您遵循这些模式。例如，我看到的常见问题之一是角色和权限。因为我知道这是一个常见的问题区域，而不是等待开发完成、将代码放到QA中、查找问题并发送回Dev，所以我能够确保BDD的一部分预先包含角色和权限，确保我的开发人员确切地理解了他们试图完成的任务。

首先思考，然后编码，

所有*DD都遵循这一基本原则。编写代码是一种特权，它是通过预先确定您将要面对的问题而获得的。虽然这并不能产生完美的代码，但它确实有助于减少错误，使每个人的生活都更好。