In WireMock, Stub priority allows us to assign priorities for the request mappings. That means it’s a simple way to resolve which stub mapping should be given more precedence if a request matches 2 or more stub mappings. It is sometimes the case that you’ll want to declare two or more stub mappings that “overlap”, in that a given request would be a match for more than one of them. By default, WireMock will use the most recently added matching stub to satisfy the request. However, in some cases, it is useful to exert more control. The standard syntax is given below in JSON format. Priority is set via the priority attribute in JSON:
{
"priority": 1,
"request": {
"method": "GET",
"url": "/api/specific-resource"
},
"response": {
"status": 200
}
}
Let’s demonstrate an example to understand how Stub Priority works in WireMock with JSON mappings.
Prerequisites:
- Refer to this article and install WireMock on your local machine: How to Download and Install WireMock?
- Refer to this article and install Postman on your local machine: How to Download and Install Postman on Windows?
- Create Your First Mocked API Endpoint with WireMock
Note: To perform Stub Priority with JUnit please refer to this article: WireMock – Stub Priority with JUnit Test
Step By Step Implementation
Step 1: Run Your Standalone WireMock Server
Open the folder in your local machine where your WireMock JAR file is present. Open the cmd on that directory and hit the following command in order to run the JAR file.
java -jar WireMockJarFileName
If everything is fine then as you can see in the below image our WireMock has been started successfully and the default port number is 8080.
Step 2: Open Postman in Your Local Machine
In the Postman, we will create 3 different stubbing with different endpoints and different priorities.
Stubbing 1: /gfg/endpoint1 with priority – 1 (Higher Priority)
{
"priority": 1,
"request": {
"url": "/gfg/endpoint1",
"method": "GET"
},
"response": {
"status": 200,
"body": "Hello Endpoint 1"
}
}
Refer to the below image if you are stuck somewhere.
Stubbing 2: /gfg/endpoint2 with priority – 1 (Higher Priority)
{
"priority": 1,
"request": {
"url": "/gfg/endpoint2",
"method": "GET"
},
"response": {
"status": 200,
"body": "Hello Endpoint 2"
}
}
Refer to the below image if you are stuck somewhere.
Stubbing 3: Generic mapping with priority – 5 (Lower Priority)
{
"priority": 5,
"request": {
"url": "/gfg/.*",
"method": "GET"
},
"response": {
"status": 400,
"body": "Not Implemented Yet"
}
}
Refer to the below image if you are stuck somewhere.
Now let’s get these stubs. If you hit the following URL http://localhost:8080/gfg/endpoint1 you are going to get the following response
Hello Endpoint 1
Refer to the below image if you are stuck somewhere.
Similarly, If you hit the following URL http://localhost:8080/gfg/endpoint2 you are going to get the following response
Hello Endpoint 2
Refer to the below image if you are stuck somewhere.
But if you are hitting any other endpoint except endpoint1 and endpoint2 then you are going to get some other response. For example, If you hit the following URL http://localhost:8080/gfg/endpoint5 you are going to get the following response
Not Implemented Yet
Refer to the below image if you are stuck somewhere.
So what does it mean?
If you see closely endpoint1 and endpoint2 are also coming under the generic mapping (/gfg/.*) but though these endpoints have the priority: 1 so they are returning the corresponding response. But endpoint5 is a generic mapping so it’s returning the generic response.
Conclusion
Stub Priority can also be used to define a default response in Wiremock for all the endpoints that are not having any stubs. If not configured, Wiremock will return its generic response like “No matching stubs found” etc., but stub priority allows you to configure that by creating a catch-all kind of stub with a lower priority value.
