When and how much should I test third-party code integration when practicing behavior driven development (BDD)?

Question

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?

Answer 1

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.

As admin
I want to sort my products
So that I can find things easily by name.

A scenario is a specific example of the behavior of a feature, and normally uses the "Given, When, Then" syntax:

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.

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.