State management

Most of the backend services tend to have some state, which changes as user interact with it. So to be able to simulate this, mock JSON response introduces scenario-based mapping.

How to adjust your stub to make it stateful.

Just add scenario and state attributes to the request object in the stub.

1. scenario (required): this attribute helps to classify the group of stubs together for state management.

2. state (required): attribute defines the state of the stub.

3. targetState (optional): attribute that defines the next state of the stub

when the program is initialized, the state of a scenario will always be 'init'.

In State management, MJR will divide the scenario further into stages. During a stage, the response belonging to that stage is mapped. Then how would the state progress? On request like POST, PUT, DELETE, the stage will be changed (with the value of the matched stub's state).

For example:

pre_list.js

request: {
        scenario: "shopping list",
        state: "init",
        method: "GET",
        urlPath: "/mock/list",
        headers: {
            "x-route": {
                equalTo: "items-list"
            }
        },
    },
    response: {
        status: 200,
        inlineData: { 
            list: ['Furits','Veggies']
        }
    }

add_to_list.js

request: {
        scenario: "shopping list",
        state: "init",
        targetState: "state_2",
        method: "POST",
        urlPath: "/mock/list",
        headers: {
            "x-route": {
                equalTo: "items-list"
            }
        },
    },
    response: {
        status: 200,
        inlineData: {
            message: "Item Added"
        }
    }

post_list.js

request: {
        scenario: "shopping list",
        state: "state_2",
        method: "GET",
        urlPath: "/mock/list",
        headers: {
            "x-route": {
                equalTo: "items-list"
            }
        },
    },
    response: {
        status: 200,
        inlineData: { 
            list: ['Furits','Veggies','Bread']
        }
    }

In the above example, all the 3 stubs are bind via "shopping list" scenario. When a first GET request is called, MJR will scan for the match request and get 2 requests, but selects pre_list request, since the state value is 'init', which indicates that the stage is initial. When POST request is received it's processed and the stage is set to the targetState of that selected stub. In this case, "state_2". Now when GET request, post_list request is selected as presetStage of the stub is "state_2".

//stage: init
GET http://localhost:3000/mock/list
{ "list": ['Furits','Veggies'] }


//stage: init -> state_2
POST http://localhost:3000/mock/list
{ "message": "Item Added" }


//stage: state_2
GET http://localhost:3000/mock/list
{ list: ['Furits','Veggies','Bread'] }

To reset the scenario, one can POST a request to http://localhost:3000/__admin/:scenario_name/reset, setting "add" as scenarion_name will reset all the scenarios.