5

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 admin@mycompany.com 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.

Newton
  • 151

2 Answers2

11

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.

Lunivore
  • 4,242
0

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.

SaxonMatt
  • 101
  • 1