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.

Tip

Whether to model dependent tests as single or multiple-stage tests is totally up to you! In general, if a stage is used in many other tests (such as the authorization step in this test), it makes sense to create a separate test definition for that stage and leverage the requires keyword in dependent tests to avoid duplication.

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!