Wiremock misleadingly tells it failed to communicate with admin endpoint

I’ve encountered a weird issue today with verifying if a call was made to wiremock with a specific parameter. At first I thought it might be the underscore char (‘_’) I used, but when I wrote a test to verify if it I found a more basic case. Analyse the code below:

    @Rule
    public WireMockRule wireMockRule = new WireMockRule(8090);

    @Test
    public void wiremockTest() {
        //GIVEN
        stubFor(get(urlMatching("/test.*"))
                .willReturn(aResponse()
                        .withStatus(200)));
        final Client client = ClientBuilder.newClient();

        //WHEN
        client.target("http://localhost:8090/test")
                .queryParam("query", "param")
                .request().get();

        //WHEN
        verify(1, getRequestedFor(urlMatching("/test.*")).withQueryParam("query", matching("param")));
    }

Everything will work fine. However if the call did not contain the query parameter or we want to verify a different query parameter, like this:

verify(1, getRequestedFor(urlMatching("/test.*")).withQueryParam("queryyyyy", matching("param")));

then the test fails with this message:

com.github.tomakehurst.wiremock.client.VerificationException: Expected status 200 for http://localhost:8090/__admin/requests/count but was 500
    at com.github.tomakehurst.wiremock.client.HttpAdminClient.postJsonAssertOkAndReturnBody(HttpAdminClient.java:147)
    at com.github.tomakehurst.wiremock.client.HttpAdminClient.countRequestsMatching(HttpAdminClient.java:101)
    at com.github.tomakehurst.wiremock.client.WireMock.verifyThat(WireMock.java:254)
    at com.github.tomakehurst.wiremock.client.WireMock.verify(WireMock.java:267)
    at pl.kmejka.wiremocktest.WiremockTest.wiremockTest(WiremockTest.java:32)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at com.github.tomakehurst.wiremock.junit.WireMockRule$1.evaluate(WireMockRule.java:67)
        ...

To run this test I had to specify these dependencies in my pom.xml:

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>com.github.tomakehurst</groupId>
            <artifactId>wiremock</artifactId>
            <version>1.53</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>javax.ws.rs</groupId>
            <artifactId>javax.ws.rs-api</artifactId>
            <version>2.0.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.glassfish.jersey.core</groupId>
            <artifactId>jersey-client</artifactId>
            <version>2.17</version>
        </dependency>

Let me know if I could help you with this issue, I’d be more than glad to help, but I could use a push in the right direction as I don’t know the codebase at all.

[jterhune]

I debugged and in my case the response coming back from the wiremock server was java.lang.NoClassDefFoundError: javax/servlet/http/HttpUpgradeHandler. I added the servlet 3.1 API to our test dependencies and the problem went away: javax.servlet:javax.servlet-api:3.1.0

[tomakehurst]

If you change the port number and want to use the static DSL, you need to tell the static client instance what the new port number is: WireMock.configFor(8090)

Alternatively (and this is faster as it doesn’t go over the wire) you can stub against the rule: wireMockRule.stubFor(...)