Forum Discussion
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']}
- LennSar3 years agoContributor
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