When our software outputs JSON, it can be hard to test. Consider this code:
1 2 | assertThat(someJson) .isEqualTo(expectedJson); |
Assuming the rendering of the resulting json matches the spacing of the expected JSON, this will work. When it doesn’t work, we get a big old string diff result telling us that the strings were different.
But JSON isn’t a String
What we really want is for mismatched JSON assertion errors to contain some clues about why it was different. We also don’t want to have to render the JSON in some perfect form if it can be avoided.
Using string comparison for JSON is an Assertion Diversion. It makes us work hard to get the comparison we want.
JSON often contains unpredictable values
The results of a web service call may contain either fields we don’t care about (the url of the server in a _self field), or a timestamp or variable ID, that change from time to time.
We want to be able to either ignore such fields, only focus on the fields we’re interested in, or apply a fuzzy assertion to the output data.
JSON Assertions
The JSONAssert library has been useful for JSON comparisons, but it has some shortcomings:
- Its custom matchers are hard to use
- It supports tree matching only
- It has minimum configurability/customisation
- It can only be used as a standalone assertion
- It can only be used with JSON Strings
I’ve previously augmented it with some additional usability features, but the time has come to offer my own solution.
Based on the style of AssertJ, and provided both as standalone assertions and as both Hamcrest AND Mockito matchers, ModelAssert is almost feature complete.
It allows matching of values within the tree, comparison of trees, subtrees, customisation, support for YAML, serialization of objects into JSON on the fly, and fuzzy assertions.
More to follow soon.
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: All Our Assertion Problems Opinions expressed by Java Code Geeks contributors are their own. |
