Is there a way to store multiple request body (json) objects so that you can toggle between them for test data? Similar to the test events you can store in AWS Lambda. Thx in advance!
1 Like
Hi @bcummins 
Unfortunately no but this sounds like a great feature addition that could help users with their testing 
We track our requests/issues publicly on GitHub and would love for you to file this request there so other customers can also weigh in. Our product managers use that feedback to prioritize and add items to our development roadmap. Thanks in advance!
Thx, @Kurmavatar…done! bkc
1 Like
Is there an update on this feature?
I did read the feature request, but I’m not 100% sure on what this is meant to achieve.
Purely from a testing perspective.
You need to have a known state, so sending dynamic bodies that return different results is counter productive.
It needs to return the same info every time.
If you are expecting different results, then these should be in separate requests.
Otherwise, what tests\assertions are you going to have. Will you want those to also be dynamic? Which is where you start getting into a mess.
I do get its the same API\endpoint, but I would still break this down into individual requests in the main.
Let’s say we don’t expect a response (a 202 for example), in which case it becomes meaningless to discuss outcomes or build test cases around different responses. A list of variants (body request) while making an API call would be a convenient and very useful feature IMO, instead of creating duplicate requests having variations just to the request payload.
But surely if you are testing a 202 status, you would have a request crafted to produce that response code each and every time.
Your tests in the tests tab would be looking for that status and would fail if it had any other status, so having a drop down that allows you to change the body would potentially break the test doesn’t sound right.
If you don’t expect that response or don’t care about the status, then you should be testing for no response or have other elements to test against.
A request without tests is just that, a request.
I might be missing some point here. I just don’t understand the feature from a testing perspective. Unless the point is so that you can break the test easier to prove you are not getting a false positive.
The original post mentioned test data.
Therefore I assume the data is meant to drive some tests. From a testing perspective, it either proves something is working or doesn’t.
I can also imagine this has issues with reporting and request\test names.