Request and response definitions
Duplicate configuration (Java DSL)
This inspection reports duplicate configuration in ResponseDefinitionBuilder call chains.
withHeader()
When a header name is specified in multiple .withHeader() calls, that header’s value would be overridden, thus this inspection to deduplicate them.
Via ResponseDefinitionBuilder
//Both "Accept-Language" string literals are highlighted
aResponse().withHeader("Accept-Language", "HU").withHeader("Content-Length", "1024").withHeader("Accept-Language", "JP");
//Both ACCEPT_LANGUAGE constant expressions are highlighted
aResponse().withHeader(ACCEPT_LANGUAGE, "HU").withHeader("Content-Length", "1024").withHeader(ACCEPT_LANGUAGE, "JP");
A quick fix is also available (since v1.0.1) to remove duplicate calls for the header name, keeping the call that the user invokes the quick fix on:
//From (where 'Accept-Language: HU' is selected to be kept):
aResponse().withHeader("Accept-Language", "HU").withHeader("Accept-Language", "JA");
//to:
aResponse().withHeader("Accept-Language", "HU");
//From (where 'Accept-Language: JA' is selected to be kept):
aResponse()
.withHeader("Accept-Language", "HU")
.withHeader("Content-Length", "1024")
.withBodyFile("filename")
.withHeader("Accept-Language", "JA")
.withHeader("Accept-Language", "RU");
//to:
aResponse()
.withHeader("Content-Length", "1024")
.withBodyFile("filename")
.withHeader("Accept-Language", "JA");
Via MappingBuilder
The logic is the same here, including the quick fix.
//From (where 'Accept-Language: HU' is selected to be kept):
stubFor(get(urlEqualTo("/path"))
.withHeader("Accept-Language", equalTo("HU"))
.withHeader("Accept-Language", equalTo("JA"))
.willReturn(aResponse()));
//to:
stubFor(get(urlEqualTo("/path"))
.withHeader("Accept-Language", equalTo("HU"))
.willReturn(aResponse()));
Via RequestPatternBuilder
The logic is the same here too, including the quick fix.
//From (where 'Accept-Language: HU' is selected to be kept):
verify(getRequestedFor(urlEqualTo("/")).withHeader("Accept-Language", equalTo("HU")).withPort(8080).withHeader("Accept-Language", equalTo("JA")));
//to:
verify(getRequestedFor(urlEqualTo("/")).withHeader("Accept-Language", equalTo("HU")).withPort(8080));
withQueryParam()
When a header name is specified in multiple .withQueryParam() calls, that header’s value would be overridden.
A quick fix is also available to remove duplicate calls for the query param name, keeping the call that the user invokes the quick fix on.
Via MappingBuilder
//From (where 'language=HU' is selected to be kept):
stubFor(get(urlEqualTo("/path"))
.withQueryParam("language", equalTo("HU"))
.withQueryParam("language", equalTo("JA"))
.willReturn(aResponse()));
//to:
stubFor(get(urlEqualTo("/path"))
.withQueryParam("language", equalTo("HU"))
.willReturn(aResponse()));
Via RequestPatternBuilder
//From (where 'language=HU' is selected to be kept):
verify(getRequestedFor(urlEqualTo("/")).withQueryParam("language", equalTo("HU")).withPort(8080).withQueryParam("language", equalTo("JA")));
//to:
verify(getRequestedFor(urlEqualTo("/")).withQueryParam("language", equalTo("HU")).withPort(8080));
ResponseDefinitionBuilder#with*Body*()
When the response body is defined multiple ways (or even multiple times the same way), it can be confusing which body is actually applied, and these definitions will override each other.
This inspection supports the following response body definition calls: withJsonBody(), withBody(), withBase64Body(), withBodyFile().
Regardless if multiple of the same method, or different methods are called, they are all reported and highlighted when duplicates are found.
stubFor(get("/").willReturn(aResponse().withBodyFile("path/to/a_file.json").withBody("{\"aJson\": \"string\"}")));
The related quick fix removes duplicate calls, keeping the call that the user invokes the quick fix on.
//From (where the first 'withBodyFile()' call is selected to be kept):
aResponse().withBodyFile("path/to/a_file.json").withBodyFile("path/to/another_file.json");
//to:
aResponse().withBodyFile("path/to/a_file.json");
//From (where the 'withBody()' call is selected to be kept):
aResponse()
.withBodyFile("path/to/a_file.json")
.withBase64Body("eyJhSnNvbiI6ICJzdHJpbmcifQ==")
.withHeader("Accept-Language", "HU")
.withBody("{}")
.withFixedDelay(200)
.withJsonBody(jsonBody);
//to:
aResponse()
.withHeader("Accept-Language", "HU")
.withBody("{}")
.withFixedDelay(200);
withStatus()
This part of the inspection detects withStatus() calls that are specified in call chains in which the first call in the chain already configures the status code behind the scenes.
It also provides a quick fix to remove the redundant withStatus() call.
Examples:
//Chains started with WireMock.aResponse() are not analyzed, since this is probably the most common way of starting a response definition,
// regardless there is a default status value, 200, set when calling only aResponse().
stubFor(WireMock.post("/").willReturn(aResponse()));
stubFor(WireMock.post("/").willReturn(aResponse().withStatus(301)));
//The following ones are all reported (the list is not comprehensive):
stubFor(WireMock.get("/").willReturn(WireMock.ok().withStatus(200)));
stubFor(WireMock.get("/").willReturn(WireMock.okForContentType("application/json", "{}").withHeader("Location", "location").withStatus(500)));
stubFor(WireMock.get("/").willReturn(WireMock.status(301).withStatus(400).withHeader("Location", "location")));
Duplicate configuration (JSON DSL)
This inspection reports duplicate configuration in response and request properties in mapping files.
| Detected property type | Supported property names | Since | Comments |
|---|---|---|---|
| body | body, base64Body, bodyFileName, jsonBody | | |
| url | url, urlPattern, urlPath, urlPathPattern |  | According to the WireMock JSON schemas, in terms of the request url definitions: “Only one of url, urlPattern, urlPath or urlPathPattern may be specified” |
Regardless if multiple of the same property, or different properties are specified, they are all reported and highlighted if duplicates are found.
Also, the related quick fix removes duplicate properties, keeping the property that the user invokes the quick fix on.
Example – body:
//From (where 'body' is selected to be kept):
{
"request": { ... },
"response": {
"status": 200,
"bodyFileName": "a/response_body.json",
"body": "{\"aJson\": \"string\"}",
"base64Body": "eyJhSnNvbiI6ICJzdHJpbmcifQ=="
}
}
//to:
{
"request": { ... },
"response": {
"status": 200,
"body": "{\"aJson\": \"string\"}"
}
}
Example – url:
//From (where 'urlPattern' is selected to be kept):
{
"request": {
"method": "GET",
"url": "/url",
"urlPattern": "/url-pa.*ern"
},
"response": { ... }
}
//to:
{
"request": {
"method": "GET",
"urlPattern": "/url-pa.*ern"
},
"response": { ... }
}
Code completion for Content-Type header values
This completion provides suggestions for the Content-Type header values in multiple places in the Java and JSON DSL.
Java DSL
It is available in header value parameters of ResponseDefinitionBuilder.withHeader() and MappingsBuilder.withHeader() calls when the header name is Content-Type.
- The following matchers are supported:
equalTo(),equalToIgnoreCase(),containing(),matching(),notMatching(). - Completion in
matching()andnotMatching()is not available by default. For them to work, the language injection called WireMock String Value Matchers must be turned off inSettings > Editor > Language Injections.
| ResponseDefinitionBuilder | MappingsBuilder |
 |  |
JSON DSL
It is available in header value string literals within request.headers.Content-Type and response.headers.Content-Type in stub-mapping files.
- The following matchers are supported:
equalTo,contains,doesNotContain, include theandandorcombined matchers. matchesanddoesNotMatchmatchers are not supported because those values are injected with RegExp language, and that injection cannot be turned off at the moment.
