上下文：我正在尝试使用Capybara / Steak进行集成测试，在Ruby on Rails环境中练习BDD，因此这将是我使用的示例，但这个问题是关于BDD的一般性问题最佳实践。
说我有一个（诚然是广泛的）用户故事如下：
Feature:
As an administrator
I should be able to manage my products
我一直在研究Rails 3的ActiveAdmin gem，它允许您使用简单的DSL创建复杂的管理界面。虽然节省时间的潜力巨大，但它也让我很难将这么多功能卸载到第三方代码而不进行测试。
但是，我被告知你通常只需要测试自己编写的代码。因此，按照这种逻辑，我只需要测试ActiveAdmin是否正确集成，因为这是我实际编写的唯一代码。测试这个的基本方案可能是：
Scenario:
Given I have 20 products
When I visit the product index page
Then I should see 20 products.
这是ActiveAdmin开箱即用的功能。所以我可以使用ActiveAdmin的文档进行基本安装并创建产品管理页面，方案将通过。
当然，我还集成了大量其他方案，例如：
Given I have 20 products
And my products include Apples, Bananas, and Berries
When I sort my products by name
Then Apples, Bananas and Berries should be on the first page in that order.
Given I have 20 products
And my products include Apples, Bananas, and Berries
When I type 'ap' into the Filter by Name field
Then I should see "Apples"
And I should not see "Bananas"
等。等
据推测，这些已经由ActiveAdmin进行了测试，因此我不需要再次测试它们，即使它们对我的应用程序至关重要。所以我想我已经完成了，可以转到另一个功能（？）。
TL; DR ：我的基本问题是，我是否应该为排序和过滤等关键功能编写方案，即使它们已经由外部库提供并且我已经测试了我的应用程序与该库的集成？
答案 0 :(得分：5)
BDD和场景的主要优点是，它可以让您通过有关场景的对话分享共同的理解。
由于看起来你是团队中唯一的人，你从场景中获得的价值将来自于思考它们，为将来捕获它们“你”将使用它们来提醒已经存在的东西已经开发并自动化它们用作回归测试。
如果你觉得它们很明显，你就不会拥有来捕获或自动化场景。对于使用库的明显功能，应该足以了解该功能，并且只在奇怪的小边缘情况下编写场景（如果存在的话）。
这是因为BDD的主要焦点不是测试。 BDD提供词汇和对话框架，以帮助我们分享理解 - 特别是发现误解 - 使软件更易于更改和维护。我们可以自动化作为一个不错的副产品。
如果您想实际测试您的应用程序的工作方式，那么您应该继续这样做。如果您没有更改正在测试的位，那么您只需要手动测试一次。
作为一个注释，你会混淆故事和场景模板，这将无济于事。故事通常是通过功能进行的小切片，这些功能已被分解以更快地获得反馈。
As admin
I want to sort my products
So that I can find things easily by name.
场景是特征行为的一个特定示例，通常使用“Given，When，Then”语法：
Given I have a 120 products
And my products include Apples, Bananas and Berries
When I sort my products by name
Then Apples, Bananas and Berries should be on the first page in that order
And the products should be paginated.
快速回答，然后：不，您不需要为软件库提供的行为编写方案。您可以手动测试它们，然后转到更有趣的东西。