Assertions in BDD scenario

Question

I am trying to understand how to correctly create my BDD REST testing scenarios.

From what I have read online, we should have only one WHEN-THEN pair and the assertions should be done in the THEN step.

What if we had a situation such as

Given user searches for flight

And user picks seat

And user adds bags to flight

When user purchases flight

Then flight is successfully booked

What happens if we get a 500 Status error when we try to add the bag to flight. Should we at the very least do basic assertions in all steps?

Answer 1

You can add assertion at all steps.

From what I have read online, we should have only one WHEN-THEN pair and the assertions should be done in the THEN step

The main assertion of scenario can be done at Then step. Below example is from my current project and you can see how I am writing steps,

@TC_CUE_Search_for_all_templates_and_validate_particular_template_response
Scenario: Validate json details for given template
Given Get template key and Application key from db
And Load Datasheet for Iteration
And Execute the request to fetch all the templates of an application
Then Get and verify the response of given template from template result list

Given Get template key and Application key from db

I validate whether DB is returning valid response or not. If I receive valid response then I fetch the required details from DB and write it in excel.

And Load Datasheet for Iteration

Reads the excel sheet.

And Execute the request to fetch all the templates of an application

GET request will be executed and I validate the response code and store the result.

Then Get and verify the response of given template from template result list

Here I do the main validation. In earlier step, it returns huge response and I fetch the particular response based on the parameter and verify all the required fields.

Purpose of this example is to clarify how you can automate REST scenarios.

Answer 2

Ideally, you only exercise one aspect of behaviour per scenario. A scenario has three parts:

Given *a context*  
When *an event occurs*  
Then *an outcome should happen*

The Given is the context in which the scenario takes place. It shouldn't matter, for the purposes of the scenario, how we got there. So for instance, if your user has added bags, it shouldn't matter whether that happened through the Gui, or through hacking data into the back end. As long as you can't tell the difference, it's fine. You can have multiple Givens, because lots of things might lend themselves to the context.

It's normal to only have one When, because it's the trigger for the behaviour you're trying to exercise. The exception I've found is for when an interaction is occurring, for instance with another person or with time, and you need them both to properly demonstrate the behaviour.

The Then is the outcome that should result from the behaviour. You can have multiple Thens as there may be multiple stakeholders or different things that have to happen - for example, when an Uber driver accepts your booking, they get the successful confirmation of their acceptance, you get notified, and Uber get to know about it too.

So, if you want to check the behaviour of being able to add bags to the flight, that should probably be an explicit scenario in its own right. You could do it as part of the "When" if you wanted:

Given the user has selected flight B1234 LON-YYZ 22 Oct 2021 16:45
And the ticket costs $240
And extra bags cost $40
And an exit row upgrade costs $20
When they book the flight with 2 bags and an upgrade to the exit row
Then their ticket should show 2 bags and an upgrade to the exit row
And they should be charged $300.

Note I've put two aspects of behaviour here: bags, and exit row upgrades. I'm pretty pragmatic about this, but if it starts to get complicated for any reason, separate them out

The important thing is that you'll notice they're both finally exercised in the When.

If you get a 500 error while setting up the Given, that's not really part of the scenario. You may however choose to run longer tests, like smoke tests or customer journeys. Strictly speaking those aren't BDD scenarios, but I've found it's usually worth having a few of them (really, they take ages to run so keep the number small!)

You'll end up with a structure like this:

Given the user is on the flight search page
And Flight B12345 leaves LHR for YYZ at 16:59
When they search for a flight from LHR to YYZ on 22 Oct 2021
Then Flight B12345 should show up in the results
When they add an extra bag and an exit row seat to the booking
Then the bag and exit row seat should show in the checkout
When they checkout...

etc.

The "Thens" scattered throughout this customer journey are looking at places where interim outcomes are achieved; either things that the customer can save for later, or places where they get feedback on what they've just done. It's still from the customer's point of view; we don't mention 500 errors. If you get a 500 error it will fail anyway, but we don't want to litter the codebase with these kinds of checks, so we don't tend to make them explicit.

Part of this is because these aren't really tests! They're living examples of how the system works that happen to provide tests as a nice by-product. They help developers understand the system and change the code easily; preventing bugs, more than catching them.

Having said that, I do sometimes put assertions in any Given that might fail. I would probably check that the website was up as part of the very first step. Any other web-based issues I'd allow to surface as part of the rest of the journey.

You may also find this answer on longer customer journeys useful.