Hi @Tom, is there any way to handle Thread Safety with a stateful behavior in wiremock, ? we have scenario , where we first have success scenario for API and then reset the scenario and after resetting , the same API returns Error . I know the scenario part we can achieve through Stateful behavior . but how we can achieve this is multi thread environment. cc : @Rajesh Narayanappa

Hi @Jai Nigam are you looking for thread safety i.e. a particular kind of consistency between multiple threads acting on the same data? Or are you looking for isolation i.e. being able to run separate tests in parallel that happen to share a WireMock instance?

Hi @Tom, I am looking for solution for both .

Are you creating your stubs programmatically or via JSON files? If you’re doing it programmatically, I suggest (if this is feasible within your API design) to dynamically create scenarios per thread/test. You’d need to ensure you pick unique stub URLs (or other matching criteria) so that the stubs you create in a given test are only ever matched by calls made from within it. If you add some uniqueness to the scenario name when you set these up, this should guarantee you get consistent behaviour.

We are creating stubs programatically.

It depends on the API and the app under test as to whether you can do this, but say you have the ability to get and put a user profile record via the API. You can create a set of stubs e.g. for

/users/12345

in one thread with a scenario name of something like

user-update-12345

. Then you ensure in your tests you specifically work with user

12345

. Then in other tests you pick a different user ID/random number/whatever and that way both the stubs and the scenario will only apply to the test/thread that created them.

Okay,

BTW, I’m seriously mulling over a new capability for the scenarios feature where it’s possible to specify request elements to make up part of the scenario key. This would mean you could e.g. make the API key or session ID part of the scenario key, and provided you generated a unique one of these per test/thread this would solve this problem more elegantly.