Now, let’s put it all together into one test that has multiple stages.
This allows us to execute multiple requests that are dependent on each other without needing to write multiple test files.
Setting up
Since the login API should be called first, and is used in any subsequent requests, we define it in the setup stage.
This is mostly just a semantic distinction, since stages are executed in order, you could also define it first in the list and the behavior would be the same.
As before, we’re simply calling the endpoint with our credentials and storing the token in a variable.
Executing stages
Here, we define multiple stages that we want to execute, and each one supports the request, compare, and response blocks.
First, we’ll call the status v1 endpoint and check the status code, just to make sure it’s up and running.
If that stage succeeds, we’ll then move on to comparing the two versions of the API, just as we did previously.
We can define any number of stages here, and they’ll be executed in order. As soon as any stage fails, the test will be considered failed.
Next, we’ll give you some next steps to keep building on the concepts learned here!