|Summary:||Incorrect display of decimal numbers in JSON related elements|
|Component:||Main||Assignee:||JMeter issues mailing list <issues>|
|Version:||Nightly (Please specify date)|
Description eR@SeR 2021-05-19 21:11:47 UTC
Created attachment 37869 [details] wrongDisplayOfDecmalNumber Hello, In the attached test plan, there are JSON Extractor, JSON JMESPath Extractor, JSON Assertion, JSON JMESPath Assertion, and Response Assertion elements. There are several issues found when the test is executed: 1. Provided decimal number is shown as the scientific notation "2.1474836475E9" in VRT (JSON, JSON Path Tester, and JSON JMESPath Tester), but it should be "2147483647.5000". Same number is shown if "$.number" or "number" JSON paths are used in corresponding JSON Testers. ---- 2. JSON Assertion shows the message "Value expected to be '2147483647.5000', but found '2147483647,5'". Expected result should be "2147483647.5000", and assertion should pass. ---- 3. JSON JMESPath Assertion shows the message "Value expected to be equal to 2147483647.5000". From this message it cannot be known what value is evaluated from the provided path. The expected message could be "Value expected to be '2147483647.5000', but found '2147483647,5'", same as in JSON Assertion (if the assertion fails of course). The expected result should be "2147483647.5000", and the assertion should pass. ---- 4. JSON Extractor and JSON JMESPath Extractor extract values as the scientific notation "2.1474836475E9" so when variables are checked in Response Assertion they fail. Please check Debug Sampler in VRT. The expected result should be "2147483647.5000". IMO, all JSON-related elements should evaluate literal decimal numbers since they cannot be properly asserted without using a code (String.format() function for example). P.S. I use non-English localization settings where the decimal number symbol is a comma. Jmeter 5.5 e0e9787 Microsoft Windows 10 Enterprise 64-bit java version "15.0.1" 2020-10-20
Comment 1 Felix Schumacher 2021-05-30 10:27:14 UTC
I think this bug would be (at least partly) solved by using the patch from bug 65299. The remaining broken assertions would be the plain text assertions, but they are plain wrong :) @Nikola, are you able to patch the source yourself and give it a try?
Comment 2 eR@SeR 2021-05-30 11:45:35 UTC
Hi Felix, Could you send me a compiled version to check it, please?