I have created a stubbed web service to help my team implement and “integration” test their code without traversing the full stack, which is not possible in this case.
I want to create some different scenarios for them e.g. success, different kinds of failure. One way I have thought of handling these scenarios is if a particular input is e.g. “Smith” then return one object, if “Jones” return another.
I’m wondering if this scenario mapping is too fragile but mainly how I could manage these scenarios in a nice way that would allow the devs to extend the scenarios. One idea was to serialize the possible results they expect and store them with their parameters in a repository of some sort. This means they could be added to and amended. The serialization could break though and for complex object it would be awkward.
Feel like I’m really missing something here!
I really love stubbing out things like web services during development. It allows the developers to target a system that might not be ready and still get work done. Like you said it also allows them to integrate early, which is great. When the actual service is ready, it should be easy to swap out the stubs for the actual service.
I think it’s totally fine to create a simple/quick-and-dirty repository that mimics actual web service calls. One set of parameters comes in and then some data goes back out.
Consider spending a few hours to write a tool that generates code/data structures for you. You can write functions that generate random data (names, addresses, whatever) and then it’s fairly easy to change parameters and re-generate stubbed data/stubbed code.
It’s worth the work to stub stuff out because it will dramatically increase developer productivity. I wouldn’t be afraid to spend a day or two setting up something – it’ll pay off over the life of the project.