You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm on a project where we're using JSON matching for our integration tests to check actual results against fixture files. We use the matchers with RestAssured like this:
It works great for checking success/failure, but the debug message when failing is, frustratingly, just a copy of the entire expected vs actual JSON content, for example:
java.lang.AssertionError: 1 expectation failed.
Response body doesn't match expectation.
Expected: {
"foo": "bar",
"zig": "zag"
}
Actual: {"zig": "zag", "foo": "baz"}
Which is problematic when working with large JSON bodies.
It looks like #44 would be a full solution to this problem, but has issues of its own (how to skip past ignored fields, for example).
A simpler fix would save us a huge amount of time: as well as providing the mismatched content, also give the path to the first failure. Something like:
java.lang.AssertionError: 1 expectation failed.
Response body doesn't match expectation.
Expected: {
"foo": "bar",
"zig": "zag"
}
Actual: {"zig": "zag", "foo": "baz"} First mismatch: $.foo
The text was updated successfully, but these errors were encountered:
I did some more investigation and found that RestAssured uses its own match failure messages by default (which is where the output above is coming from). So I guess this isn't an issue to raise here.
I'm on a project where we're using JSON matching for our integration tests to check actual results against fixture files. We use the matchers with RestAssured like this:
It works great for checking success/failure, but the debug message when failing is, frustratingly, just a copy of the entire expected vs actual JSON content, for example:
Which is problematic when working with large JSON bodies.
It looks like #44 would be a full solution to this problem, but has issues of its own (how to skip past ignored fields, for example).
A simpler fix would save us a huge amount of time: as well as providing the mismatched content, also give the path to the first failure. Something like:
The text was updated successfully, but these errors were encountered: