我们的应用程序的基础是一个大的配置集，它定义了抽象的设备组，它们作为小黄瓜场景的一部分无处不在。
现在我们像这样使用给定的步骤作为我们的Gherkin规范的一部分:
Given the device is a Zebra
Zebra在本例中只是实际组的占位符，但它包含许多不同的特定设备。像这样的语句非常方便，但它也使这个场景无法测试，因为你必须为每个特定的设备自动执行这个场景，我不知道有任何框架会有这样的功能。场景概述也不是一个解决方案，因为你几乎在所有场景和/或功能文件中都有这个设备列表的副本。
这个问题有什么可能的解决办法吗?也许我们这样使用BDD是完全错误的，但是您如何处理这种配置问题呢?如果你只是想在特定类型的所有场景之前设置一个上下文(你的设备列表)，那么这是一个非常好的background context的例子;很少更改的长期数据，并且在所有场景中都存在。许多BDD框架提供了工具，使您能够在特性/场景文件的顶部设置背景。比如黄瓜就有背景;JBehave使用GivenStories。
对于没有提供这种工具的框架，可以跳过该步骤的细节，只要每个使用它的人都能很好地理解它。比如你可以说:
Given the standard device list
And a Zebra from that list
这将允许您仅用几行来完成此操作，而设备列表的详细信息隐藏在步骤定义中。
然而，如果你想尝试运行每个设备的场景只是为了检查它是否有效，那么这可能超出了BDD的范围，当然也超出了BDD框架的范围。
BDD并不是关于严格的回归测试。它是关于捕获系统如何行为的具体示例，最好是通过与专家(理解问题的人，如业务代表)、测试人员和开发人员的对话。如果你有一个设备以一种特定方式运行的例子，通常就足以捕捉到这种理解，至少从BDD的角度来看。
如果你必须为每个设备执行一个场景只是为了彻底，那么使用像JUnit这样的东西是可以的。如果你愿意，你仍然可以使用Given/When/Then语法，无论是作为代码中的注释，还是通过创建自己的DSL，但是如果你找到了其他表达测试值的方法，那么就不要被BDD的语法或BDD工具所限制。这不是测试事物的唯一方法。