在实践行为驱动开发 (BDD) 时，我应该在什么时候测试第三方代码集成以及测试多少？

Question

上下文：我正在尝试在 Ruby on Rails 环境中使用 Capybara/Steak 进行集成测试来练习 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：我的基本问题是，我是否应该为排序和过滤等关键功能编写场景，即使它们已经由外部库提供并且我已经测试了我的应用程序与该库的集成？

Answer 1

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.

然后快速回答：不，您不需要为软件库提供的行为编写场景。您可以手动测试它们，然后继续做更​​有趣的事情。