testing - 在实践行为驱动开发 (BDD) 时，我应该何时以及在多大程度上测试第三方代码集成？

Question

上下文:我正在尝试使用 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:我的基本问题是，我是否应该为排序和过滤等关键功能编写场景，即使它们已经由外部库提供并且我已经测试了我的应用程序与该库的集成？

Answer 1

BDD 和场景的主要优点是它可以让您通过关于场景的对话分享共同的理解。

因为看起来你是团队中唯一的人，你从场景中获得的值(value)将来自于思考它们，为 future 的“你”捕捉它们，他们将使用它们来提醒已经发生的事情已开发，并将它们自动化以用作回归测试。

如果您认为场景很明显，您不必捕捉或自动化场景。对于使用库的明显功能，了解该功能应该就足够了，并且只围绕奇怪的小边缘情况编写场景(如果存在的话)。

这是因为 BDD 的主要关注点不是测试。 BDD 提供了一个词汇和 session 框架来帮助我们分享理解——尤其是发现误解——使软件更容易更改和维护。我们将自动化作为一个不错的副产品。

如果您想实际测试您的应用程序如何工作，您应该继续这样做。如果您不更改要测试的位，则只需手动测试一次。

请注意，您混淆了故事和场景模板，这无济于事。故事通常是功能的一小部分，这些功能已被分解以更快地获得反馈。

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.

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