Spurious failure with "request was unmatched by any stub matching" since upgrade to WireMock 2.9.0

Without changing any of our own code, updating from WireMock 2.8.0 to 2.9.0 causes many tests to fail with spurious “unmatched request” errors.

Example test:

@Test
public void testAuditLogRequestHeader() throws Exception
{
    callingOurStuffHere();
    verify(postRequestedFor(urlEqualTo("/1/team/log/get_events"))
               .withHeader("Authorization", WireMock.equalTo("Bearer " + TOKEN))
               .withRequestBody(equalToJson("{}")));
}

Failure text:

com.github.tomakehurst.wiremock.client.VerificationException: A request was unmatched by any stub mapping. Request was: 

	at com.github.tomakehurst.wiremock.client.VerificationException.forUnmatchedRequests(VerificationException.java:92)
	at com.github.tomakehurst.wiremock.junit.WireMockRule.checkForUnmatchedRequests(WireMockRule.java:90)
	at com.github.tomakehurst.wiremock.junit.WireMockRule.access$000(WireMockRule.java:34)
	at com.github.tomakehurst.wiremock.junit.WireMockRule$1.evaluate(WireMockRule.java:74)
	at com.acme.common.test.rules.BaseTestRule$1.evaluate(BaseTestRule.java:45)
	at com.acme.common.test.rules.BaseTestRule$1.evaluate(BaseTestRule.java:45)
	at com.acme.common.test.rules.BaseTestRule$1.evaluate(BaseTestRule.java:45)
	at com.acme.common.test.rules.BaseTestRule$1.evaluate(BaseTestRule.java:45)
	at com.acme.common.test.rules.BaseTestRule$1.evaluate(BaseTestRule.java:45)
	at com.acme.common.test.rules.Timeout$CustomFailOnTimeout$StatementRunner.run(Timeout.java:137)
	at java.lang.Thread.run(Thread.java:745)

The odd thing is how it doesn’t actually print out anything…

This appears to occur consistently for tests using verify(postRequestedFor(...)) but tests using stubFor(post(...)) still pass.

[tomakehurst]

OK, so you’re not actually creating any stubs here. WireMock’s default behaviour is to fail your test if you’ve made requests that it hasn’t been able to match, on the assumption that this probably means you’ve missed something. This is analogous to the approach some object mocking tools take where unexpected calls are considered errors.

Two options to fix this:

1. Stub the call being made so that there’s something to match it (I’d consider this best practice)
2. Disable the failure behaviour by setting failOnUnmatchedRequests to false in the rule constructor.

[hakanai]

I’ve ended up updating all the tests using verify to use stubFor instead, and they’re passing, so I’ll just close this. Thanks for the info.