I have been implementing several REST API tests in a BDD fashion using Cucumber and was thinking of a scenario where an Activity object with a certain id can be retrieved through the GET endpoint. An example found on the internet checks first if a list of activities is available, before actually retrieving that specific id.
Thus, the scenario (in the feature file) looks like this:
Scenario: When user requests for an existing activity id, the activity should be returned
Given A list of activities is available
When The user requests for an activity with a specific id
Then The requested activity should be returned
In the Given step, I will send a GET request to my API in order to check that activities can be provided. In the When step, I will request for a specific activity (providing its id), while in the Then step I will do my assertions.
Other sources state that it is not recommended to directly interact with the API in the Given step, and just prepare internal data (like creating objects internally or generating an id to be inserted), and then send it to Then, which should actually do the interaction with the external system.
My question would be: are there specific rules on what to do in the Given step and what not? If I consider that before getting an activity with a certain id, I should insert it, for example, and also check if the insertion was successful, am I not allowed to write the POST logic inside the Given statement? If so, doesn't this mean that most of the Given implementations are going to be empty for simple APIs?
This is a matter of opinions.
You prepare the system under test in the arrange part, Given etc. It sounds to me like you are using an external client to do some black box testing on a server that already is running. In this situation, I would not worry too much about doing a POST in a Given step. Unless it is possible for you to check the state of the server through some other channel, maybe looking in a database or similar.
In other words, each situation is unique and you do what you need to make sure the end goal is reached, a system working as the end users need it to work. While, if possible, avoiding maintenance nightmares in the future.