Bug 65299 - JSONPathAssertion attributes are out of order
Summary: JSONPathAssertion attributes are out of order
Status: NEEDINFO
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 5.4.1
Hardware: PC All
: P2 normal (vote)
Target Milestone: JMETER_5.5
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-11 06:33 UTC by AG
Modified: 2021-05-30 12:49 UTC (History)
0 users



Attachments
Compare JSON objects and not their string representations. (14.02 KB, patch)
2021-05-11 18:30 UTC, Felix Schumacher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description AG 2021-05-11 06:33:33 UTC
I use JSONPathAssertion for Assertion,but the result is failure ,because attributes are out of order.

Info:
resoponse: 
{"a":{"b":{"componentSn":false,"stolen":false,"wepFlag":false,"matchExchangeRule":false,"matchRefurbishRule":false,"needHideActivationDate":false}}}

Asser JSON Path exists:
$.a.b

Expected value:
{"componentSn":false,"stolen":false,"wepFlag":false,"matchExchangeRule":false,"matchRefurbishRule":false,"needHideActivationDate":false}

result:
Assertion failure message:Value expected to match regexp 
'{"componentSn":false,"stolen":false,"wepFlag":false,"matchExchangeRule":false,"matchRefurbishRule":false,"needHideActivationDate":false}', but it did not match: '{"matchExchangeRule":false,"componentSn":false,"stolen":false,"wepFlag":false,"needHideActivationDate":false,"matchRefurbishRule":false}'


I have try to modify the code like this.., it worked.

class JSONPathAssertion
 
public static String objectToString(Object subj) {
        String str;
        if (subj == null) {
            str = "null";
        } else if (subj instanceof Map) {
           // str = (new JSONObject((Map) subj)).toJSONString();
            str = new Gson().toJson(subj);
        } else if (!(subj instanceof Double) && !(subj instanceof Float)) {
            str = subj.toString();
        } else {
            str = ((DecimalFormat) decimalFormatter.get()).format(subj);
        }

        return str;
   }
Comment 1 Felix Schumacher 2021-05-11 18:30:26 UTC
Created attachment 37855 [details]
Compare JSON objects and not their string representations.

When using our stringifier, the order of the entries in maps
is not guaranteed and can lead to wrong results.
    
In the old days we made no difference between a string or int
when asserting a result. Jackson JSON Parser differentiates
between 'foo' and '"foo"' (former is invalid) and '1' and '"1"'
(former is an int, latter a string).
    
To enable both (complex, simple and edge cases), we now have to do
more work.

@OP I saw no guarantees from Gson#toJson(obj) that it prints keys in a
stable way. You might have been lucky with your experiments. Could you try
the attached patch and report, if it works for you?