Skip to content

4. Multiple Stages

multistage.jkt
name: Multistage Test
tags: regression
setup:
request:
method: Post
url: https://api.jikken.io/api/v1/examples/login
body: {
"username": "testuser",
"password": "password"
}
response:
status: 200
extract:
- name: token
field: auth.token
stages:
- request:
url: https://api.jikken.io/api/v1/examples/status
headers:
- header: Authorization
value: ${token}
response:
status: 200
- request:
url: https://api.jikken.io/api/v2/examples/status
headers:
- header: Authorization
value: ${token}
compare:
url: https://api.jikken.io/api/v1/examples/status
response:
status: 200
ignore:
- user.lastActivity

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

setup:
request:
method: Post
url: https://api.jikken.io/api/v1/examples/login
body: {
"username": "testuser",
"password": "password"
}
response:
status: 200
extract:
- name: token
field: auth.token

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

stages:
- request:
url: https://api.jikken.io/api/v1/examples/status
headers:
- header: Authorization
value: ${token}
response:
status: 200
- request:
url: https://api.jikken.io/api/v2/examples/status
headers:
- header: Authorization
value: ${token}
compare:
url: https://api.jikken.io/api/v1/examples/status
response:
status: 200
ignore:
- user.lastActivity

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!