Support for injections

[dan-schofer]

I'm interested in dynamically changing responses based on previous requests to the same imposter/stub, like what is described in the MB docs here: http://www.mbtest.org/docs/api/injection

Does this API support injections or would that require more work? I couldn't find any support myself looking through.

It appears that behaviors like a decorator could do this too: http://www.mbtest.org/docs/api/behaviors

[AngelaE]

The API does not support injections at the moment. What is your use case?

[dan-schofer]

I'd like to modify a response based on the previous response by the same stub on the same imposter.

Please let me know if more detail will help!

[AngelaE]

More detail would be helpful. Is your API making 2 requests to the same endpoint of another service during one request?

[dan-schofer]

That's exactly right, two identical requests to the same external service endpoint that expect different responses b/c of additional processing that happened in between.

[AngelaE]

I do not have time at the moment to implement this functionality, and so far not needed it. If there are other options to set up the tests I would recommend avoiding the injections. It will be much harder to find problems in your tests with that in comparison to really simple imposters.

Options:

1. Preferred: Assuming you are not calling the same dependency twice within the same API call you could set up your imposter new between calls. We have found that this really simplifies the imposters and problem analysis/maintainability for tests.
2. If one API call queries the same endpoint multiple times you could return different responses, see http://www.mbtest.org/docs/api/stubs. However - this behavior seems very chatty and there is a performance/reliability impact for your API.

// Is this what your API does?
// In that case the option 1 does not work
=> client => your API => dependency call 
                      => dependency call with different parameters

[dan-schofer]

Thanks for the options! I was able to simplify the logic I was using and avoid the issue, but what it was doing was:

=> client => your API => dependency call to endpoing A
                      => examine response
                      => dependency call to endpoint B
                      => dependency call to endoint A with same parameters as first one

there are many reasons why this shouldn't be necessary, but b/c of limited dependency documentation it was done to be thorough and I think injections are the only option to handle that scenario, but like a said I'm able to simplify and avoid the first dependency call by assuming a little more risk.

Thanks for your help!