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?
Hey LennSar
explanation? yeah - there's a defect and it's been present since at least 2018 when I noticed it!!! 😉
I did mention it in step4 of my instructions - but I was obviously not clear enough. when I added my last post in, I tried taking a screenshot on my personal laptop, but the snipping tool closed off the form when it generated for some reason.
Tried on my work machine and snipping tool worked fine this time.
Have a look at the following:
the problem is that if you just select the relevant test step and then the response it'll just generate "${reset date#Response}" as you noticed. What you need to do is navigate from outside the teststep - (you've a helluva a lot of steps in your testcase - unsure if that's really wise, but anyway) - as I say - if you just select the step and then 'Property [Response]' it'll just generate "${reset date#Response}"
HOWEVER - if you start further up the chain, (say at TestSuite level), then TestCase, then TestStep - then select 'Property [Response]', instead of just generating "${reset date#Response}", instead after select 'Property [Response]' it'll generate a window/form where you can select the relevant attribute - once you click on 'OK' to save that - it'll generate the correct parameter (which includes the jsonpath to the attribute that is missing when you just select the teststep.
So! - step by step instructions (better than my last ones! ;))
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 and scroll passed all the individual test steps that are listed - the teststeps appear to be listed first, but after the teststeps you'll see a Project object and TestSuite objects - one for each testsuite in your project. Select the testsuite that contains your current testcase (see image below)
5. After selecting the TestSuite object you care about (the testsuite that contains your current testcase), select the relevant TestCase object (which is your current testcase) (as following screengrab)
6. Then select the relevant PUT teststep from the list (see following screengrab) - you can see the teststeps listed
7. Then select the teststep to reveal the options - one of which is 'Property [Response]' (see following)
8. Select 'Property [Response]' to generate the following form (mine is showing XPATH cos Ive used a SOAP project to demo this, but yours will be JSONPATH) - but it's equivalent
9. Select the relevant attribute, click on 'OK' button to save the changes and close the form and this will dynamically populate the Expected Results field with the value which INCLUDES the JSONPATH you need! (something like '${PUT TestStepName#Response#$['jsonpath_value_to_your_Year_attribute']}')
10. Repeat steps 3 to 9 for the other attributes (month & day)
Cool?
Cheers!
Rich
${PUT TestStepName#Response#$['jsonpath_value_to_your_Year_attribute']}
Hi richie,
thanks for the very detailed explanation. I did understand this approach in your first explanation already but while you get different behaviour in the two approaches described, I get the same! With BOTH ways I simply get the ${set date#Response} string pasted in the Expected Result tab.
I think the problem is that the put request gets it's data from a data source which gets the data from a .csv file.
Here's what the request looks like:
If I change the request body to something like "year" : 2022, everything works fine and I your above described approach works fine. Another hint is the error message on the put requests overview page:
Did I do something wrong or is this a bug?
Thanks,
Lennart
