Given this API:
{{base_url}}/json/1F/flightavailability/adults=1&departureairport=CRL&departuredate=20190509&destinationairport=CZL
All the parameters are mandatory except "adults". I need to write a BDD scenario and step definition for them to automate the scenario : response should be "422, unprocessed" if any of these mandatory parameters are missing.
I always like to have a conversation when I'm looking at BDD scenarios, even if it's for an API rather than a UI. I imagine the conversation going a bit like this:
Shobha: So you don't need to know how many adults are travelling to process this, but you do need departure airport, departure date and destination airport?
Business: That's right. If we don't know how many adults are travelling, we assume it's 1, and we give back the available flights, priced with 1 ticket. Otherwise, we show all available flights and prices for the number of adults travelling.
Tester: What if there are no flights on that date?
Business: Ah, then it should say there are no flights.
Tester: What if there's 2 adults travelling, but only 1 seat on the plane?
Business: Oh, good catch - well, we should filter that out too.
Shobha: OK, so that's 5 scenarios - the one where mandatory data is missing, the one with no flights, the one where the flight with too few seats is filtered out, the one with 1 adult by default, and the one with 2 adults.
(I put the tester in there because they're really good at spotting the scenarios that nobody else thinks of.)
So, having had the conversation about what the system should do, we now have some different scenarios.
The context in which the scenario takes place - everything that was created before-hand - is the "Given". The action that takes place (submitting a search for flights) is the "When". The outcomes that result are the "Thens". You can include the set-up of the URL in the "Given" - try to make it phrased in the language of the business if you can, rather than the language of the API.
I also like to make things concrete (provide examples of destinations, departure dates and airports), because it helps us to think about other scenarios.
So for the "mandatory data missing" scenario, I would have something like:
Given a search for a flight on 17 Sep 2028 from LHR
When the search is submitted
Then the submitter should be told that the request could not be processed
And the text should contain "missing destination airport"
I wouldn't create end-to-end scenarios for every missing field; it's enough to have one at the system level. Put the rest in unit tests (see Testing Pyramid; avoid the Testing Ice Cream Cone). When you've written them, get feedback on them to see if you understood correctly.
Your post is missing information about what happens in the event of a successful submission; I have made many assumptions here! I would probably group the successful submissions with the unsuccessful submissions, unless there are too many and it gets confusing, then split them up.
Of course, you might just be testing validation / anti-corruption layers! But if you're doing that, just do it in unit tests - you don't need BDD tools.