All our affirmation problems | Java code geeks


When our software generates JSON, it can be difficult to test. Consider this code:

1

2

assertThat(someJson)

   .isEqualTo(expectedJson);

Assuming the rendering of the resulting json matches the expected JSON spacing, this will work. When that doesn’t work we get a big old string diff result telling us the strings were different.

But JSON is not a string

What we really want is for the mismatched JSON assertion errors to contain clues as to why it was different. We also don’t want to have to render the JSON in perfect form if it can be avoided.

Using string comparison for JSON is assertion deviation. 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 fields that are not of interest to us (the server url in a _self field), or a timestamp or variable ID, which change from time to time.

We want to be able to either ignore these fields, focus only on the areas that interest us, or apply afconfused statement to the output data.

JSON assertions

the JSONAssert The library was useful for JSON comparisons, but it has a few shortcomings:

  • Its custom matchers are difficult to use
  • It only supports tree matching
  • It has minimal configurability / customization
  • It can only be used as a stand-alone assertion
  • It can only be used with JSON strings

I have already augmented it with a few more usability features, but now is the time to come up with my own solution.

Based on the style of AssertJ, and provided both as stand-alone assertions and as both Hamcrest AND Mockito correspondents, ModelAssert is almost complete.

It enables within-tree value matching, comparison of trees, sub-trees, customization, YAML support, on-the-fly serialization of objects to JSON, and fuzzy assertions.

More to follow soon.

Posted on Java Code Geeks courtesy of Ashley Frieze, partner of our JCG program. See the original article here: All our affirmation problems

The opinions expressed by contributors to Java Code Geeks are their own.



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *