在实践行为驱动开发 (BDD) 时，我应该何时以及多少程度地测试第三方代码集成？
上下文：我尝试在 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：我的基本问题是，我是否应该为排序和过滤等关键功能编写场景，即使它们已经由外部库提供，并且我已经测试了我的应用程序与那个图书馆？
Context: I am trying to practice BDD in a Ruby on Rails environment using Capybara/Steak for integration tests, so that will be the example I use, but this question is a general question about BDD best practices.
Say I have an (admittedly broad) user story like so:
Feature:
As an administrator
I should be able to manage my products
I have been looking at the ActiveAdmin gem for Rails 3, which allows you to create sophisticated admin interfaces using a simple DSL. While the time-saving potential is huge, it also scares me to off-load so much functionality to third-party code without testing at all.
However, I've been taught that you generally only need to test code that you write yourself. So, by that logic, I just need to test that ActiveAdmin is integrated properly, since that's the only code I'm actually writing. A basic scenario to test this might be:
Scenario:
Given I have 20 products
When I visit the product index page
Then I should see 20 products.
This is a function offered by ActiveAdmin out of the box. So I could do the basic installation and create the Products Admin page using ActiveAdmin's documentation, and the scenario will pass.
Of course, then I have also integrated a massive number of other scenarios, such as:
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"
etc. etc.
Presumably though, these have already been tested by ActiveAdmin and so I shouldn't need to test them again, even though they are critical to my application. So I guess I'm done, and can move on to another feature(?).
TL;DR: My basic question is, should I be writing scenarios for critical functionality like sorting and filtering, even if they are already provided by an external library and I have tested my application's integration with that library?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
BDD 和场景的主要优点是，它可以让您通过有关场景的对话来分享共同的理解。
因为看起来你是团队中唯一的人，所以你从场景中获得的价值将来自于对场景的思考，为未来的“你”捕捉它们，未来的“你”将使用它们来提醒已经开发的内容，并将它们自动化以用作回归测试。
如果您认为场景很明显，您就不必捕获或自动化这些场景。对于使用库的明显功能，了解该功能应该足够了，并且仅围绕奇怪的小边缘情况（如果存在）编写场景。
这是因为 BDD 的主要焦点不是测试。 BDD 提供了词汇和对话框架来帮助我们分享理解，特别是发现误解，使软件更易于更改和维护。我们将自动化作为一个很好的副产品。
如果您想实际测试您的应用程序如何工作，您应该继续这样做。如果您不更改正在测试的位，则只需手动测试一次。
请注意，您混淆了故事和场景模板，这没有帮助。故事通常是功能的一小部分，为了更快地获得反馈，这些功能已被分解。
场景是功能行为的具体示例，通常使用“Given、When、Then”语法：
快速回答，然后：不，您不需要为软件库提供的行为编写场景。您可以手动测试它们，然后继续进行更有趣的事情。
The main advantage of BDD and scenarios is that it lets you share a common understanding through conversation about scenarios.
Since it looks like you're the only person on the team, the value you'll get from scenarios will come from thinking them through, capturing them for the future "you" who will use them as a reminder of what's already been developed, and automating them for use as regression tests.
You don't have to capture or automate scenarios if you think they're obvious. For obvious functionality which uses a library, it should be enough to be aware of that functionality, and only write scenarios around odd little edge cases if those exist.
This is because BDD's main focus is not about testing. BDD provides a vocabulary and conversational framework to help us share understanding - and, particularly, discover misunderstandings - making the software easier to change and maintain. We get to automate as a nice by-product.
If you want to actually test how your application works, you should go ahead and do that. If you're not changing the bits you're testing, then you only need to test it manually, once.
As a note, you're confusing the story and scenario templates, which won't help. Stories are normally small slices through features which have been broken down to get feedback faster.
A scenario is a specific example of the behavior of a feature, and normally uses the "Given, When, Then" syntax:
Quick answer, then: No, you don't need to write scenarios for behavior provided by software libraries. You can test them manually, then move on to the more interesting stuff.