(bug?) - json path match assertion with wildcards 'select from current' results in failureSOLVED
(bug?) - json path match assertion with wildcards 'select from current' results in failure
When I "select from current" in a JSON path match assertion the assertion actually fails.
The field in JSON looks like this:
"field" : "targetOffice"
The select from current sets the assertion to "targetOffice" (including the double quotes), while actual value is asserted as targetOffice.
////Update: Wildcard enabled should be ticked. When unticked it's fine. This is not a specific 3.0 issue. Modified the subject line to rectify this.
Solved! Go to Solution.
This seems very similar to an issue someone else raised maybe 6 to 8 weeks ago where the string type was maintained in assertion when it wasn't before. I'm typing this out on my phone so cant find the relevsnt post.
Whatever it looks like a couple of issues (that youve posted on) have been introduced with the latest version. Id raise a service ticket with Smartbear as theyll need to know if they dont already.
I got no other help for you im afraid!
Support request Case 00413341 logged.
Hi Nmrao. No difference with appended .
What I do notice:
This is specifically for an assertion that was already created in version before 3.0. Basically, this test step is a copy paste of a step created in 2.8. I just wanted to update that existing assertion for jsonPath $['errors']['field'] with the correct value. That gave me above error. When I add the same assertion again to the test step via add assertion - for content I get proposed the same json path, $['errors']['field'] ... but there the proposed expected result is correct (also when I update it from Select From Current). All other assertions I created in 2.8 are still valid. So I guess thise lowers the severity/priority, but it still is curious how 2 exactly the same json path assertions behave differently...
See posts below... nothing to do with v2.8 v3.0. It is just the wild card enabling that causes this behaviour...
Just a wild guess that expression from 2.8 contains some not visible character that matters during the match.
Wonder what if you look into your project file using some text editor (e.g. Notepad++) with special characters display option turned on?
/Alex [Community Hero]
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
No, that wasn't the difference.
But that showed me in the right direction, so thank you @AlexKaras .
It is actually the "allow wildcards" check that explains the behaviour. Nothing to do with the v2.8 vs 3.0, sorry for bringing that up. I never thought allowing wild cards would make the assertion fail. No valid reason for that in my view, so I guess it stays a bug 🙂
<con:assertion type="JsonPath Match" name="Match content of [field] smartbear bug - https://community.smartbear.com/t5/SoapUI-Pro/V3-0-bug-json-path-match-assertion-select-from-current-results/m-p/193622#M44379" id="652853cc-94e3-4003-ac79-85af27bf5d60" disabled="true"> <con:configuration> <path>$['errors']['field']</path> <content>"targetOffice"</content> <allowWildcards>true</allowWildcards> <ignoreNamspaceDifferences>false</ignoreNamspaceDifferences> <ignoreComments>false</ignoreComments> </con:configuration> </con:assertion> <con:assertion type="JsonPath Match" id="11a67e54-d8a4-4fe8-924a-67690f6364af" name="Match content of [field]"> <con:configuration> <path>$['errors']['field']</path> <content>"targetOffice"</content> <allowWildcards>false</allowWildcards> <ignoreNamspaceDifferences>false</ignoreNamspaceDifferences> <ignoreComments>false</ignoreComments> </con:configuration> </con:assertion>