Hi <@U03N1E342B0>, is there any way to handle Thre...
# general
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.
How I will ensure about unique stub URL and matching criteria, currently we are using default request matching from wiremock
do I need to implement request matching
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
in one thread with a scenario name of something like
. Then you ensure in your tests you specifically work with user
. 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.
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.
And you wouldn’t (necessarily) have to vary the URL per test this way