This message was deleted.
# helps
Slackbot
09/04/2023, 8:56 PMThis message was deleted.
t
Tom
09/04/2023, 9:01 PMWhat you’ve described is very sensible. Having a (relatively small) common set of stubs that must always be present for basic functioning then adding higher priority, more specific examples from individual test cases is a strategy I use quite frequently.
Tom
09/04/2023, 9:03 PMI’d say generally it’s best to avoid having lots of long-lived stubs if possible.
The nice thing about creating them in code and blowing them away at the end of the test is that there’s minimal risk of unintended behaviour when the stub you didn’t expect gets matched, and also you you don’t have a big maintenance problem when the API is updated - just update the code that generates your in-test stubs.
n
Natalia Alehina
09/04/2023, 9:16 PMThanks! Then I'll follow this strategy, any hint on how to make a relatively small set of stubs? For example, (imaginary situation as short explained as i can) you have GET
v1/order/itemv1/order/sellerstubFor(get(urlMatching("order").willReturn...ordert
Tom
09/05/2023, 10:09 AMWhat I mean is it’s best to keep the set that are always present to a small size. Typically I’ll only do this for things that are used during every test setup, or called routinely e.g. endpoints that return lists of reference data.
The temporary stubs you create for individual tests can be as abundant as you need them to be. Since they’re scoped to a single test and cleared out (by calling reset before each test or using the rule/extension to do so) each time they’ll never get out of hand, nor will they leak into other test cases.
2 Views