Hey LennSar
I'm not really understanding what you mean by "forward the send parameter in the put request to the equal assertion of the get request."
However, I think youre talking about Property Transfer - which is pretty straightforward and there's a number of ways to get it done.
I answered a similar question yesterday, see the following link --> https://community.smartbear.com/t5/ReadyAPI-Questions/How-define-testscenario-for-REST-requests-using-values-of/m-p/232452
However - if the above link doesn't help - if you provide more info - exactly what you mean - by "forward the send parameter in the put request to the equal assertion of the get request." - then we'll be able to answer your question.
At this point the only thing I'm sure of is you have a PUT request and you're following up with a GET to confirm the changes made by the PUT - that's all I got.
If you can clarify exactly what you mean - that would be great!
Cheers,
Rich
Hi richie
sorry for the lack of detail. The property transfer function doesn't really seem to do what I want. Let me clarify by using an example:
I have a put request that sets the current date. So the json body looks like this:
{
"year" : 2022,
"month" : 2,
"day" : 22
}
If I run a get on the same node I get the above as a json response. Now I'd like the assertion to check whether the response of the get is the same as the parameters (year, month, day) from the put request.
What I can do is compare one of the parameters of the get against the entire body of the put request, which of course leads to the error in the below screenshot:
What I would like to have to is either an assertion that doesn't check one item in the get response but the entire response against the body of the put request or to have the possibility to compare one item of the get reponse with one parameter of the put request.
Hope this helps to understand what I'm looking for!
Thanks,
Lennart
Hey LennSar ,
easiest way to do this (and also the best way from a Quality Assurance perspective! - cos...well....we're supposed to care about that sort of thing! ;))
1. Ensure you have both your PUT request and GET request in your TestCase already.
2. Execute both the PUT request and the GET request so that you have the responses generated
3. On your GET request, add a Content Match Assertion (on the 'Year' attribute) to launch the following form
4. Click on the 'Select Content' button to launch the form which allows you to select content. Click on the option within the generated form that is the PUT request test step, then click 'Property [Response]' from the listing - this will generate the following screenshot (note: it can be really fiddly to get this function to work on some ReadyAPI instances. If you can't generate the form by just clicking on the PUT test step, instead navigate through from scratch - select the correct testsuite, then the correct testcase, then the PUT request, then select 'Property [Response]' (pretty sure there's a ReadyAPI defect in this functionality - but if you navigate through from the TestSuite - it'll work fine)
5. At this point, select the 'Year' attribute within the form and click on 'OK' (the form closes) and the 'Expected Result' field in your Content Match Assertion will display a value like the following:
${PUT TestStepName#Response#$['jsonpath_value_to_your_Year_attribute']}
6. Click on 'Save' to save and close the changes.
7. Repeat steps 3 to 6 for the other attributes (month & day)
done! 🙂
If you want, there are other comparison options we can discuss (groovyscript and more complex testcase object hierarchies) - but I think they're overkill when you can just do it like this
Cheers,
Rich
Hi richie,
that sounds like exactly what I was looking for and I actually tried that approach before but the result is that from the screenshot in my second post. Instead of giving me the pop up you showed everything closes down and what I get is "${reset date#Response}" which is the complete body. It's the same on both approaches you described.
here's a screenshot to show what you described in your first approach:
I'm using Ready API 3.30.0 which should be the latest version right? Any suggestion why it behaves this way? Do you have an example project that I could use for a comparisson?
