Removing matching requests from request journal

[mic...@tado.com]

Hi,

we are using a standalone WireMock to verify HTTP requests in our tests. In order to isolate the test cases, we need to reset the request journal before each test case. But since we are running the tests in parallel (using Gradle maxParallelForks), resetting the whole journal is not an option.

Do you have any suggestion how to handle this use case?

So far we have come up with these idea: Add possibility to remove only matching requests. That way we could workaround the problem by removing only requests expected by the current test.

This could be achieved in two ways:

1. Extend WireMock core
• add new method to RequestJournal interface: void resetRequestsMatching(RequestPattern requestPattern);
• add corresponding Admin API
2. Add Admin Extension
• as far I can see, this would require quite some reflection hacks, since there is no Admin API

If you think that this is a reasonable feature, we are happy to work on it and submit a PR.

Any feedback would be greatly appreciated!

Thanks,

Michal

[Tom Akehurst]

Might be a bit late for a reply to be useful, but I'll answer anyway...

In this situation I usually just run more than one WireMock instance. It can be a bit fiddly doing randomised ports correctly, but I've always found a way. If all else fails I build a little config util method that opens a ServerSocket, grabs its local port number, then closes it. This gives a pretty good guarantee that the port is free and random, provided you use it quickly afterwards. Doing this means you can pick the port number eagerly, and therefore use it in your app config.

[Florian Rampp]

Hi,

I am working with the original author of this issue.

In this situation I usually just run more than one WireMock instance. It can be a bit fiddly doing randomised ports correctly, but I've always found a way. If all else fails I build a little config util method that opens a ServerSocket, grabs its local port number, then closes it. This gives a pretty good guarantee that the port is free and random, provided you use it quickly afterwards. Doing this means you can pick the port number eagerly, and therefore use it in your app config.

This is not an option for us since we start the application under test (using Grails, --> starting time ~1-2min) with the target port of WireMock configured. And we cannot dynamically change the configuration of the application for different specs. And this would anyway not work because wir concurrently run specs issuing concurrent requests to the same application instance.

Any other suggestion or would you approve the change mentioned by Michal above? Which way would you chose?

Florian

[Tom Akehurst]

Right, understood. I worked on a Grails app for a client a couple of years ago and had exactly the problem you've described.

The way we managed it on that occasion was to create all of our stubs (via builders) in our test cases and ensure that we generated data that was unique enough to avoid any given stub being hit by more than one thread (or test case even). We found that worked for most cases, and where we had globally scoped data (e.g. reference data) we just bootstrapped it in an idempotent way at the start of the test suite (I think we did a create-if-absent type thing).

Having said all that I realise there might be cases where this strategy is hard to pull off, so to answer the original question I'd be open to a selective delete function for the request log (provided it also supported deleting by ID).