Bug #11807
Baselines captured on different environments may use different line termination characters which fail the text comparisons
Status:
New
Priority:
Normal
Assignee:
-
Start date:
Due date:
% Done:
0%
billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:
History
#2 Updated by Artur Școlnic 5 days ago
If a client captures a baseline json for the harness to use, it will have CRLF /r/n for new lines, if the tests are ran on linux, the end chars will be LF /n, this results in a failed test. IMO we need to make the text comparison with the sanitized versions of both baseline and test result, or better yet, if we are comparing jsons, compare the json data, not text.
#3 Updated by Șerban Bursuc 5 days ago
#4 Updated by Constantin Asofiei 5 days ago
The issue is not the JSON file encoding, but OS-style line endings captured in field values and escaped, like \r\n for CRLF on Windows; this is an example response which can exist in the baseline:
{
"details": "{\r\n\"message\": \"no problems\"\r\n}"
}
We can not decide automatically to replace these values - in some cases, the caller may actually expect these values.
What I think we can do:- mark certain fields in the JSON as being another JSON, and let FWD compare 'json to json' this field's value
- automatically replace \r\n with the OS-style line ending from the env where this is ran - this can be done via a flag, and only for field values.