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

Lunivore · Answer 1 · 2017-02-24T14:18:42.537

1

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.

edited Feb 24 '17 at 14:18

answered Feb 22 '17 at 00:09

Lunivore

17,277
4
47
92

Thanks for your insight. It _is_ in fact the algorithm I'm after here, i.e. that a progress indicator is displayed after x seconds elapses during an in-flight async operation. I do like the GWT comments approach because of the expressivity and clarity the grammar brings to even technical unit tests. "[BDD]...it's not really about the desired behaviour of the system; it's about the desired behaviour of the users." I'm a little confused by this statement, as it seems to contradict Dan's definition WRT "behavior" (system vs users): https://youtu.be/qWsnmx45734?t=51s – Tony D Feb 23 '17 at 03:22
@TonyD For unit-level BDD, the user is another class. Imagine you are that class. Work out how you want to use the class you're about to write. Can you come up with an example? If so, this is BDD! You're thinking about how the class's behaviour will deliver value to the users (other classes), rather than worrying how it will behave internally. My comment "it's not really about the desired behaviour of the system" was about aesthetics, not about BDD, so I will edit to be clearer. – Lunivore Feb 24 '17 at 14:15
Ah. Yes, it was my misinterpretation of the subject of "it" that was throwing me off. Your edit clears it up. Thanks! – Tony D Feb 24 '17 at 16:05

score 0 · Answer 2 · answered Feb 21 '17 at 12:38

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?

score 0 · Accepted Answer · answered Feb 21 '17 at 12:53

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.

Hi Kyle, your example is helpful and I understand my scenario is not really a business-y thing. As @Lunivore suggested, I'll probably make this a lower-level test and convert the GWT to comments. One question about your example: Should `And the ticket is not scanned at "LGW"` start with `But` instead of `And`? — Tony D, Feb 23 '17 at 03:31
It can be either, `And` or `But` both make sense in that scenario. After you saying that though, my instinct is telling me to change it to a `But` solely because it is referencing a negative precondition rather than a positive one. It's all about preference really when it comes to using `And` & `But` — KyleFairns, Feb 23 '17 at 09:48

How specific should my acceptance test example be?

3 Answers3