I was writing some tests in Gherkin (using Cucumber/Specflow). I was wondering how abstract should I get with my tests.

In order to not make this open-ended, which of the following statements is better for BDD:

Given I am logged in with email [email protected] and password 12345
When I do something
Then something happens

as opposed to

Given I am logged in as the Administrator
When I do something
Then something happens

The reason I am confused is because 1 is more based on the behaviour (filing in email and password) and 2 is easier to process and write the tests.

2 Answers 2


They're not really tests; they're scenarios or examples of how to use your code. If you avoid the word "test" you'll have an easier time, and it will become obvious that 2 is the way forward because you'll be able to discuss your scenarios with the business.

The business have no interest in tests phrased in the way you've described in 1. Business people would generally much rather talk through an example of how to use the code, which will lead inevitably to 2.

Additionally, the fact that you're asking suggests you're not talking to the business yet. Please go have the conversations. It's the most important bit of BDD - far more important than the automation - and will save you a lot of rework and pain, as well as helping to keep the scenarios interesting and maintainable in the event that you do automate them.

That first scenario doesn't describe the behavior any differently to the second one - it just describes the mechanics of the behavior, which will make it harder to change those mechanics later, as well as introducing unnecessary detail. The only time you'd need a scenario phrased in the same way as 1 is if you're really fascinated by logging in. I would prefer to see a scenario focused on the business-valuable activity you're logging in for.

  • +1. In the first scenario the context that you are testing the login scenario of an Admninistrator so obviously 2nd case makes more business friendly. However, in certain scenarios use of examples makes more sense and in those situations, example 1 is the right choice. Read Specification By Example. Commented May 30, 2012 at 20:36
  • @Pangea I don't like the word Specification either, just because it makes people try to define their scenarios with certainty for the entire feature, instead of accepting that there will always be some uncertainty in anything new, then exploring that and trying something out to get feedback. Recognizing uncertainty is IMO far more important than eliminating it. It's just examples, conversations, desires, hopes - not specifications. But yes, if you can keep that in mind, read Specification by Example. Just replace the word Specification with Conversation and you'll be good.
    – Lunivore
    Commented May 30, 2012 at 20:40
  • Or Exploration, for that matter. Exploration by example works very well for me.
    – Lunivore
    Commented May 30, 2012 at 20:49

Another key thing to think about when penning your features and scenarios is this: If we change X in the system, will I need to refactor my scenarios? If the answer is yes, I would say that it is getting to specific about the details. IMO features and scenarios should only change because of changes in requirements from the business/stakeholders.

So in your examples: Say you change the authentication system, and it enforces a username rather than an email address as the user identifier for logging in.

In your first example you're going to have to go back to your scenario and change that. In the second example - you won't.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.