andrew_net
Occasional Contributor
Joined 9 years ago
User Profile
User Widgets
Contributions
Re: BUG? JSONPath Match works differently between SoapUI open software version and SoapUI NG (Ready!API)
Thanks for the response, Rao. Unfortunately, it is not the same. What making the matter worse is that I tested more types of checking we are using and found more problems. For the same response JSON shown above, I created the following assertions: JSONPath Match: #1.1 JSONPath: $.errors[0].code Expected value: 100 #1.2 JSONPath: $..errors[0].code Expected value: 100 #1.3 JSONPath: $..errors[?(@code == 100)] Expected value: [{"code":"100","message":"Message for 100"}] #1.4 JSONPath: $..errors[?(@code == 100)].code Expected value: [100] #1.5 JSONPath: $..errors[?(@code == 100)].message Expected value: [Message for 100] #1.6 JSONPath: $..errors[?(@code == 300)] Expected value: [] #1.7 JSONPath: $..errors[?(@code == 300)].code Expected value: [] #1.8 JSONPath: $..errors[?(@code == 300)].message Expected value: [] JSONPath Existence: #2.1 JSONPath: $.errors[0].code Expected value: true #2.2 JSONPath: $..errors[0].code Expected value: true #2.3 JSONPath: $..errors[?(@code == 100)] Expected value: true #2.4 JSONPath: $..errors[?(@code == 100)].code Expected value: true #2.5 JSONPath: $..errors[?(@code == 100)].message Expected value: true #2.6 JSONPath: $..errors[?(@code == 300)] Expected value: false #2.7 JSONPath: $..errors[?(@code == 300)].code Expected value: false #2.8 JSONPath: $..errors[?(@code == 300)].message Expected value: false The tests result are below: SoapUI (open software version): Passed: 1.1, 1.2, 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8 Failed: 1.6, 1.7, 1.8 (these three test cases should also pass) Ready!API 1.5 and 1.6: Passed: 1.1, 2.1, 2.2 Failed: 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8 So the behaivor are really different! I will attach the test case to this post, could you please take a look? Thanks. To run the test case, please start the mock service and run the test suite "TestJSONPath". Regards.1.6KViews0likes3CommentsBUG? JSONPath Match works differently between SoapUI open software version and SoapUI NG (Ready!API)
Hi, We started with SoapUI open software version 5.2.1 and are now moving to SoapUI NG (Ready!API) 1.6.0. Suddenly, our testcases began to fail. We then found that the JSONPath Match works differently between SoapUI open software version and SoapUI NG (Ready!API). Given the following response: {"errors": [{ "code": "100", "message": "Message for 100", }, { "code": "200", "message": "Message for 200", } ]} The "JSONPath Match" assertion used to work on SoapUI open software version is as below Expression: $..errors[0].code Expected result: 100 This assertion fails on SoapUI NG (Ready!API). To pass on the NG version, the assertion has to be rewritten as below (note the highlighted square bracket): Expression: $..errors[0].code Expected result: [100] Could anyone take a look and see if this is a bug? Thanks. The problem is that we use both version cross different environments (some use open software version and some use NG version), as such that it requires the same test cases working on both environments. Regards.1.7KViews0likes5CommentsRe: BUG? JSONPath Existence Match cannot use condition
Hi Tanya, Thanks for getting back to me. This is really good news! Unfortunately, I cannot test it on Ready API since my trial license is expired and I am still waiting for the approval of the real license. I tried to install the maintenance build and it still tells me the trail license is expired. Do you know if the change went into SoapUI open software version? Is there a maintenance build for the open software version I can test this on? Thanks.2.2KViews0likes3CommentsBUG? JSONPath Existence Match cannot use condition
This was discovered when I chatted about a different issue in the forum. I am posting it here so the problem is more clear and hope to get some attention. Let's say I have a response like below {"errors": [{ "code": "100", "message": "Message for 100", }, { "code": "200", "message": "Message for 200", } ]} I created "JSONPath Existence Match" asserts as below Expression: $..errors[?(@.code == 100)] Expected result: true Expression: $..errors[?(@.code == 800)] Expected result: false I would think both VALID, i.e. the actaul result of the second expression would be false. However, the actual result was true. The second assertion failed with the error: -> Comparision failed for path [$..errors[?(@.code == 800)]], expecting [false], and actual was [true] However, if I create "JSONPath Count" asserts instead as shown below: Expression: $..errors[?(@.code == 100)] Expected result: 1 Expression: $..errors[?(@.code == 800)] Expected result: 0 Both assertion will be VALID, i.e. the actual result of the second expression will be 0 (which is the expected value). This is not consistent! Should this be a BUG? I tried this on both SoapUI OpenSource 5.2.1 and the SoapUI NG Pro 1.5.0 (ReadyAPI 1.5.0). They all behave the same.Solved2.4KViews0likes6CommentsRe: How do I assert one of the objects in an array meets a condition in SoapUI by using JSONPath
How about the "JSONPath Existence Match"? If you only want to assert something shows up and don't really care how many times it shows up, then "JSONPath Existence Match" may be of use. If you do care about how many times it shows up, then you know the expected number and you can use the "JSONPath Count". Any way, I found SoapUI is not really stable. I tested "JSONPath Existence Match" approach yesterday many times and verified it worked, and then I found out it doesn't work any more just now. Or maybe I was confused??? Go back to my original example, I create two "JSONPath Existence Match" as below: JSONPath: $..errors[?(@.code==100)] Expected result: true JSONPath: $..errors[?(@.code==800)] Expected result: false When I tested it yesterday, the first one was VALID and the second one was FAILED yesterday. And now both are VALID. It doesn't really matter what value I used for comparison (100, 800, or XYZ), it always return true!!! It seems that the "JSONPath Existence Match" only fails if you write something completely wrong, e.g.: $..errors[3000] or $.errors[0].hello or $..nobodyhome Maybe it doesn't support condition in "JSONPath Existence Match"? It does support condition in "JSONPath Count" and "JSONPath Match" though.7.9KViews0likes1CommentRe: How do I assert one of the objects in an array meets a condition in SoapUI by using JSONPath
By the way, to get around the problem with multiple items, you can use "JSONPath Count" or "JSONPath Existence Match" instead of "JSONPath Match" as you see fit to assert the "number of occurences" or "existence". So the JSONPath assertions in SoapUI does meet my needs.8KViews0likes3CommentsRe: How do I assert one of the objects in an array meets a condition in SoapUI by using JSONPath
Thanks a lot, Ton646. Your solution works! I might stick with the scripting approach though since I have quite few validations and copy & paste of a customized function call is easier than creating multiple JSONPath Match assertions. While I were validating your solution, I finally figured out why my attempts of the similar approach didn't work. My previous tries were using the following JSONPath: $..errors[?(@.code=="100")].code It seemed that this expression considered the quote character (") as part of the value for comparison.8KViews0likes0CommentsHow do I assert one of the objects in an array meets a condition in SoapUI by using JSONPath
Let's say I have a response like below {"errors": [{ "code": "100", "message": "Message for 100", }, { "code": "200", "message": "Message for 200", } ]} I can assert the codes by using JSONPath like below: Expression: $.errors[0].code Expected result: 100 Expression: $.errors[1].code Expected result: 200 The problem is that the order of the objects in the array may change, i.e. 200 occurs first and 100 occurs after. So, I have to assert something like "the errros should contain an error with code 100 while the error 100 can occur anywhere in the errors array". How do I do this? Currently, I have to use Script assertion to achieve this and I am wondering if there is a better way. Thanks.Solved8.3KViews0likes6Comments