Hello everyone, I have a conceptual question regarding sharing states between requests. That states are defined independently of a request and the naming of the states in the examples in my view suggest that states might be shared between different requests. But I have made the observation that this might not always work. If my application is a To-Do list app the request to "get a todo list item" and "check a todo list item" might both use the state 'a todo list item exists'. However if I deal with the contract tests in the controller layer of the provider, the endpoints might call endpoints that require different mocking in the state, e.g. the one calls a method

getItem

and the other

setItemDone

. I so far see two options to deal with this: 1. Use two different states after all, even though the state names "an item can be fetched" and "an item can be set to done" seem to introduce even more duplication between state name, request name and test name for non-error states. 2. Set up all methods within the same state. In this case it would mean always mocking both methods, even though only one is likely required. What is the recommended way to deal with this?

Interesting question. In general I would say 'it depends', mostly on the scale of the project and the amount of duplication. If it's really only these two states you're talking about, I'd probably use one state and mock both interactions. It seems like the simpler way. But if you get to 3-4-5 interactions, things might look different. Duplication in some form is hard or even impossible to avoid. If there is a way to avoid it, it might quickly lean towards overengineering, which is not a good thing, either. So year, it depends on the setup, for me.

Okay, thanks!