Verifying

The WireMock server records all requests it receives in memory (at
least until it is reset). This makes it possible to verify that
a request matching a specific pattern was received, and also to fetch
the requests’ details.

Verifying and querying requests relies on the request journal, which is an in-memory log
of received requests. This can be disabled for load testing - see the Configuration section for details.

Like stubbing, verification also uses WireMock’s Request Matching system to filter and query requests.

Verification failures, console output and IntelliJ

When verifying via the Java API all failed verifications will result in a VerificationException being thrown.

The message text in the exception is formatted to enable IntelliJ’s failure comparison view:

Verifying in Java

To verify that a request matching some criteria was received by WireMock
at least once:

Verifying via the JSON + HTTP API

There isn’t a direct JSON equivalent to the above Java API. However,
it’s possible to achieve the same effect by requesting a count of the
number of requests matching the specified criteria (and in fact this is
what the Java method does under the hood).

This can be done by posting a JSON document containing the criteria to
http://<host>:<port>/__admin/requests/count:

Optionally the results can be filtered to those occuring after a specififed (ISO8601) date-time. Also, the result set can optionally be limited in size
e.g. to return the most recent three results after the 7th of June 2016 12pm send:
GET http://localhost:8080/__admin/requests?since=2016-06-06T12:00:00&limit=3

Criteria queries

The request journal can also be queried, taking a request pattern as the filter criteria. In Java:

Resetting the request journal

The request log can be reset at any time. If you’re using either of the
JUnit rules this will happen automatically at the start of every test
case. However you can do it yourself via a call to
WireMock.resetAllRequests() in Java or sending a DELETE request to http://<host>:<port>/__admin/requests.

Finding unmatched requests

To find all requests which were received but not matched by a configured stub (i.e. received the default 404 response) do the following in Java:

List<LoggedRequest>unmatched=WireMock.findUnmatchedRequests();

To find unmatched requests via the HTTP API, make a GET request to /__admin/requests/unmatched:

Near misses

“Near Misses” are enabled by the new “distance” concept added to the matching system.
A near miss is essentially a pairing of a request and request pattern that are not an exact match for each other, that can be ranked by distance.
This is useful when debugging test failures as it is quite common for a request not to be matched to a stub due to a minor difference e.g. a miscapitalised character.

Near misses can either represent the closest stubs to a given request, or the closest requests to a given request pattern depending on the type of query submitted.

To find near misses representing stub mappings closest to the specified request in Java: