Request Matching
- Syntax highlighting for JsonUnit placeholders
- Before-after matcher folding
- Between date-time “matcher” live template
- Nonsense matcher combinations
- Method calls with too few arguments
- Converting boolean and() and or() between WireMock and StringValuePattern variants
- Replacing date-time “now” calls with convenience method calls
- request.pathParameters has no corresponding request.urlPathTemplate property
- request.urlPathTemplate / WireMock.urlPathTemplate() has no or empty path variable defined
- request.urlPathTemplate doesn’t have matching variable name
- Generate path parameters from URL path template
- Suspicious use for regex symbols in request URL and URL path matching
Syntax highlighting for JsonUnit placeholders
Since, in WireMock
JSON equality matching is based on JsonUnit and therefore supports placeholders.
(see also the Request matching document), highlighting is added for these placeholders in JSON stub mapping files and Java classes in the parameter ofcom.github.tomakehurst.wiremock.client.ResponseDefinitionBuilder#withBody(java.lang.String)
calls.

Notes:
- This feature doesn’t include any kind of language support for JsonUnit placeholders. It is not really the scope of this plugin.
Before-after matcher folding
WireMock provides quite a handful of methods for request matching, among which there are date-time related ones. The following ones are in scope of this code folding:
before(...)
beforeNow()
after(...)
afterNow()
Chained together with and()
, these code snippets can be quite long, thus this code folding aims to lessen the cognitive load on having to read through the whole matcher expression.
In case they are used inside a matchingJsonPath
, matchingXPath
or matchesXPathWithSubMatcher
matcher, the path is included in the folded placeholder text, otherwise the subject is substituted with it
.
For now, the placeholder creation always takes the text of the after and before expressions, be it string literal, constant, or method call, and not the value they potentially evaluate to.

Inside matchingJsonPath():
unfolded: stubFor(post("/").withRequestBody(matchingJsonPath("$.date", before("BEFORE").and(after("AFTER")))));
folded: stubFor(post("/").withRequestBody(matching: "AFTER" < "$.date" < "BEFORE"));
unfolded: stubFor(post("/").withRequestBody(matchingJsonPath("$.date", before("BEFORE").and(afterNow()))));
folded: stubFor(post("/").withRequestBody(matching: [now] < "$.date" < "BEFORE"));
unfolded: stubFor(post("/").withRequestBody(matchingJsonPath("$.date", beforeNow().and(after("AFTER")))));
folded: stubFor(post("/").withRequestBody(matching: "AFTER" < "$.date" < [now]));
unfolded: stubFor(post("/").withRequestBody(matchingJsonPath("$.date", and(before("2022-02-02T00:00:00"), after("2020-01-01T00:00:00")))));
folded: stubFor(post("/").withRequestBody(matching: "2020-01-01T00:00:00" < "$.date" < "2022-02-02T00:00:00"));
Referencing constants:
private static final String AFTER_DATE = "after_date_value";
private static final String BEFORE_DATE = "before_date_value";
unfolded: stubFor(post("/").withRequestBody(matchingJsonPath("$.date", before(BEFORE_DATE).and(after(AFTER_DATE)))));
folded: stubFor(post("/").withRequestBody(matching: AFTER_DATE < "$.date" < BEFORE_DATE));
Standalone calls
unfolded: LogicalAnd and = WireMock.and(before("BEFORE"), afterNow());
folded: LogicalAnd and = [now] < it < "BEFORE";
unfolded: LogicalAnd and = before("BEFORE").and(after("AFTER));
folded: LogicalAnd and = "AFTER" < it < "BEFORE";
unfolded: LogicalAnd and = after("AFTER").and(before("BEFORE"));
folded: LogicalAnd and = "AFTER" < it < "BEFORE";
Individual before(...)
and after(...)
calls are not folded because the save on reading length is not that significant.
Between date-time “matcher” live template
Since no ‘between’ date-time matcher exists in WireMock, this live template helps to create and insert the before().and(after())
code snippet.

Nonsense matcher combinations
There are certain matcher combinations that either don’t make sense or contradict each other, so this inspection reports those cases.
For now, date-time specific matchers linked together with and()
are supported. For example:
isNow().and(beforeNow())
The full list of combinations that are reported (the operands are applicable in the reverse order as well):
Left operand | Right operand |
---|---|
isNow() | after() , before() , equalToDateTime() , afterNow() , beforeNow() , isNow() |
equalToDateTime() | after() , before() , equalToDateTime() , afterNow() , beforeNow() , isNow() |
beforeNow() | equalToDateTime() , afterNow() , beforeNow() , isNow() |
afterNow() | equalToDateTime() , afterNow() , beforeNow() , isNow() |
before() | before() , isNow() , equalToDateTime() |
after() | after() , isNow() , equalToDateTime() |
Method calls with too few arguments
There are methods that require a minimum number of arguments to be passed in. This inspection reports calls to them with a fewer number of arguments required.
Method | Required minimum no. of arguments |
---|---|
WireMock.and() | 2 |
WireMock.or() | 2 |
Converting boolean and() and or() between WireMock and StringValuePattern variants
StringValuePattern
type matchers can be combined into complex boolean matchers using and()
and or()
, and since they have static WireMock.and()/or()
and instance StringValuePattern.and()/or()
variants, it is possible to switch between the two forms.
From the fluent x.and(y)
/x.or(y)
forms the conversion is possible only when all operands are combined with and()
or or()
, respectively.
The intention is generally available if there are at least two operands specified. Bold text below means a selected code snippet.
From WireMock-based
From | To | Availability |
---|---|---|
WireMock.and(x, y, z) | x.and(y).and(z) | When cursor is on and(). |
WireMock.or(x, y, z) | x.or(y).or(z) | When cursor is on or(). |
From fluent
From | To | Availability |
---|---|---|
x.and(y).and(z) | WireMock.and(x, y, z) | When at least one x.and(y) portion of a call chain is selected. |
x.and(y).and(z) | WireMock.and(x, y).and(z) | When at least one x.and(y) portion of a call chain is selected. |
x.or(y).or(z) | WireMock.or(x, y, z) | When at least one x.or(y) portion of a call chain is selected. |
x.or(y).or(z) | WireMock.or(x, y).or(z) | When at least one x.or(y) portion of a call chain is selected. |
Note: if you want to flip the operands of a fluent call, there is already an intention coming from IntelliJ called Flip commutative method call that can do that.
Mixed
From | To | Availability |
---|---|---|
x.and(WireMock.and(y, z)) | WireMock.and(x, WireMock.and(x, z)) | When cursor is on and() . |
WireMock.and(x, y).and(z) | – | Not available. |
Replacing date-time “now” calls with convenience method calls
Since date-time matchers (after()
, before()
, equalToDateTime()
) can accept WireMock’s now offset expression format, the aforementioned methods can be called with the String value "now"
for which there are non-parametrized convenience methods.
From | To |
---|---|
after("now") | WireMock.afterNow() |
before("now") | WireMock.beforeNow() |
equalToDateTime("now") | WireMock.isNow() |
Method calls chained to the original ones (e.g. after("now").and(before("SOME DATE"))
) are kept after applying the quick fix, e.g. WireMock.afterNow().and(before("SOME DATE"))
.
request.pathParameters
has no corresponding request.urlPathTemplate
property
This inspection reports request.pathParameters
properties when there are no request.urlPathTemplate
properties specified in their corresponding stub mappings.

request.urlPathTemplate
/ WireMock.urlPathTemplate()
has no or empty path variable defined
This inspection reports the value of the request.urlPathTemplate
property when it has either no path variable defined, or at least one empty (i.e. {}
) variable.
JSON

Java

request.urlPathTemplate
doesn’t have matching variable name
This inspection reports parameters in request.pathParameters
/withPathParam()
calls when request.urlPathTemplate
/WireMock.urlPathTemplate()
doesn’t contain
path variable(s) with those names.
JSON

Java

Generate path parameters from URL path template
This intention action generates
- the
request.pathParameters
property, or missing path parameters inside it, based on the path variables in therequest.urlPathTemplate
property. withPathParam()
calls for each path variable that doesn’t have such call, based on the path variables inWireMock.urlPathTemplate()
It presumes that path variables are defined with arbitrary names enclosed by { and } curly braces.
See WireMock 3 path templates documentation.
JSON
Generate pathParameters
If request.pathParameters
doesn’t exist for a given stub mapping, it is generated along with the parameters, right after request.urlPathTemplate
.

From:
{
"request": {
"method": "GET",
"urlPathTemplate": "/v1/{some}/path/{parameter}"
},
...
}
to:
{
"request": {
"method": "GET",
"urlPathTemplate": "/v1/{some}/path/{parameter}",
"pathParameters": {
"some": {
},
"parameter": {
}
}
},
...
}
Generate all or missing parameters
If request.pathParameters
do exist, only the parameters that are not yet defined in it, are generated. They are generated at the beginning of pathParameters
, and in the same order as the parameters occur in urlPathTemplate
, and only one instance of each of them.

From:
{
"request": {
"method": "GET",
"urlPathTemplate": "/v1/{some}/path/{parameter}",
"pathParameters": {
"parameter": {
"equalTo": "value"
}
}
},
...
}
to:
{
"request": {
"method": "GET",
"urlPathTemplate": "/v1/{some}/path/{parameter}",
"pathParameters": {
"some": {
},
"parameter": {
"equalTo": "value"
}
}
},
...
}
Java
The idea is the same as for the JSON part of this feature. The calls are generated right after urlPathTemplate()
, and in the same order as the parameters occur in it, and only one instance of each of them.

From:
stubFor(get(urlPathTemplate("/v1/{some}/path/{parameter}"))
.willReturn(ok()));
to:
stubFor(get(urlPathTemplate("/v1/{some}/path/{parameter}"))
.withPathParam("some", WireMock.equalTo(""))
.withPathParam("parameter", WireMock.equalTo(""))
.willReturn(ok()));
Suspicious use for regex symbols in request URL and URL path matching
During request matching multiple approaches can be used to match URLs and URL paths.
Users may run into the case when the specified URL or path can’t be used with the specified used matching approach, and during test execution the request doesn’t match one or more requests.
To prevent such issues, URLs and URL paths that are specified as potential regular expressions are reported, so that the matching approach can be fixed if necessary.
The followings are reported:
- In JSON
request.url
property values containing any of[]{}.*+^$\|
request.urlPath
property values containing any of()[]{}.*?+^$\|
- In Java
WireMock.urlEqualTo()
call arguments containing any of[]{}.*+^$\|
WireMock.urlPathEqualTo()
call arguments containing any of()[]{}.*?+^$\|
Exact url matching excludes the check for (, ) and ? symbols, because they can be used as part of the query parameters. This way it doesn’t produce false positive reporting.

