How specific should my acceptance test example be?

Question

I'm new to Gherkin / ATDD / BDD. I'm drafting the following acceptance test:

Given a user is waiting for an operation to complete
    And the operation is <percent>% complete
When <threshold> seconds elapse
Then a progress indicator should be displayed
    And the progress indicator should display "<percent>%"

Is this specific enough or should I modify the Given clause to represent a more concrete example (thinking in SBE terms), for instance by citing a specific persona instead of just "user" or citing the exact "operation" that is in progress (e.g.: fetching customer list)?

Thanks, Tony

Answer 1

BDD

Behaviour Driven Development is all about conversations between the development team and the business. The feature files and scenarios within them should always relate to a specific business need, a feature or an ability that means that both the business and the development team are fully clear between them on exactly what is outlined.

As an example:

Feature: Rewards for frequent flyers
   As a frequent flyer
   I should receive points to my account
   So that I am more likely to book with BDD Airlines again in the future

 Scenario: I get flyer miles
   Given I book a flight 
    And this flight earns 100 miles
   When I land
   Then my account should have 100 miles added to it

The question is, does this outline the entire problem or is there more information needed? Would the development team be able to build something using this conversation (As you are on about SBE)?

Would this be better?:

Feature: Rewards for frequent flyers
   As a frequent flyer
   I should receive points to my account
   So that I am more likely to book with BDD Airlines again in the future

 Scenario: Passenger gets flyer miles
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is scanned at "LGW"
   When the flight lands at "MAN"
   Then the account 12341234 is rewarded 100 miles

 Scenario: Passenger missed their flight
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is not scanned at "LGW"
   When the flight lands at "MAN"
   Then the account 12341234 is not rewarded any miles

 Scenario: Passenger gets kicked off the plane
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is scanned at "LGW"
     But the ticket is removed from the flight
   When the flight lands at "MAN"
   Then the account 12341234 is not rewarded any miles

It's all about clarity, and is usually more about how the behaviours of the system are described in relation to the business.

Your Example

I personally wouldn't write a Scenario for the purpose of testing a progress bar, as the business shouldn't be interested in the implementation of any components used (they don't care about the loading bar, they just care that the information actually loads).

This would be better as a unit test in my opinion.

Answer 2

Yes, you should be more specific. If you have only one type of user or if this test case applies to every user group "user" is probably good enough for your test. However, I think you should specify the operation that has to be waited on, because TDD is all about feeling safe about your code and how can you be sure it is working everywhere if you haven't tested it for all the operations that could cause a delay?

Answer 3

Progress bars are asethetics.

The only real way to test an aesthetic is to show it to people and see what they think. A/B testing is really good for this. BDD isn't particularly well-suited to aesthetics, because aesthetics are not really about the desired behaviour of the system, but about the desired behaviour of the users.

We're still learning how to program people effectively. Until then, test aesthetics with humans, not scripts.

If there's some algorithm that lends itself to an aspect of behaviour of the progress bar then sure, that would be worth testing... but as others have said, that's something best left for class-level BDD, where the examples are tied more directly to the code.

At that level, you can just put the "Given, When, Then" statements in comments and it's good enough. Class-level steps aren't reused in the same way as system-level steps are, so making them into reusable abstractions isn't as important as making them easy to change. Stick with J/N/WhateverUnit and mock the rest out.