Allow field values to be ignored by specifying a JSON path

[hertzsprung]

We often have a requirement where we're not interested in the value of a field, but we do care that the field exists. This might be an autogenerated ID or a timestamp for example.

It would be useful to specify the field(s) as a JSON path expression so that we can be selective in which fields get ignored.

[carterpage]

Any idea what this might look like to a programmer?

[hertzsprung]

Thinking some more, we probably want to make this feature more flexible than just "ignore a field's value". From a hamcrest point-of-view, it would be good if we could say to JSONassert, "compare these two documents, but if you see a node matching , ignore it". That way, I can make my assertions on particular paths separately. Something like this:

assertThat(myActualDocument, both(
    sameJSONAs(myExpectedDocument).ignoringPath("$.library.book.id"))
   .and(path("$.library.book").hasField("id"))) // I'm making this syntax up here ;-)

Or we could maybe have

assertThat(myActualDocument, both(
    sameJSONAs(myExpectedDocument).ignoringValueAtPath("$.library.book.id"))

When I get some time, I'm going to play with https://github.com/jayway/JsonPath and see what might work.

[carterpage]

I get it now. I think the concept is useful. My main question now, is what is the proper syntax? Your example almost reminds me of JPA, which is not a bad convention. Still, it is pretty different from the straight-forward "compare X with Y" of JUnit.

One other thing, JSONAssert should already be able to figure out whether a node matches something like "$.library.book.id" without requiring a 3rd-party library. If you want to get more sophisticated with the JSON queries, you might need something else, but integration may prove tricky.

[hertzsprung]

Right, my example was written in a hamcrest style (since I'm writing the hamcrest-json library). I'm not yet sure how to surface this feature in JSONassert itself but you're right, we should probably stick with the existing style. If we /do/ want to integrate a third party JSON path library, we might want to make it an optional dependency. One of the good things about JSONassert is that it needs almost no dependencies!

[ibrahimover]

Hi,

I need this ignore field functionality, but it seems like it might take a while to agree and finalize this issue, meanwhile i would like to get benefit of using JSONCompareResult,

Is there any date set for 1.1.2 release?

[hertzsprung]

You're right, this feature isn't done yet but it's good to know I'm not the only one that needs it ;-) What in particular are you looking for from JSONCompareResult?

[ibrahimover]

I was hoping to get list of failure from _fieldFailures and exclude some fields manually but after a bit of investigation currently it only holds the failures on value comparison, all the missing, and unexpected messages are being appended to actual message String so i can not have those fields as a list.

[hertzsprung]

Yes, my idea for JSONCompareResult is that it should provide you with a model of the failures (including missing fields, unexpected fields and mismatched fields). Doing that was higher up my TODO list, so I will try and get round to that one 😃

[carterpage]

How about something like adding this signature to JSONAssert:

JSONAssert.assertEquals(String exp, String act, JSONCompareMode mode, JSONConstraint constraint)

It could work something like this:

JSONConstraint constraint = JSONConstraint.ignoreValueAtPath("$.library.book.id");
JSONAssert.assertEquals(expected, actual, STRICT, constraint);

Constraint gives us theoretically infinite flexibility in terms of what we want to throw into the calculation.

---

To take it further, we could even consider making JSONCompareMode a child of JSONConstraint to reduce the number of variables. In that case the signature could look like this (I've renamed some classes, but we'd make sure we do this in a way to maintain backwards compatibility with previous releases):

JSONAssert.assertEquals(String exp, String act, JAConstraint constraint)

And it could work like this in a simple case:

JSONAssert.assertEquals(expected, actual, JACompareMode.STRICT);

Or:

JAConstraint constraint = JACompareMode.STRICT.ignoreValueAtPath("$.library.book.id");
JSONAssert.assertEquals(expected, actual, constraint);

I imagine the ability to chain constraints like this to make them easier to write:

JAConstraint constraint = JAConstraint.ignoreValueAtPath("$.library.book.id")
                                      .ignoreValueAtPath("$.library.book.title");

[btiernay]

I too need this feature for the same reason (generated id fields). Any progress on this feature?

[hertzsprung]

@carterpage At the risk of sounding like a fanboy, I think the API would start to look a lot like Hamcrest's, only Hamcrest is already very composable and has lots of useful features that already exist ;-) (see my earlier example)

@btiernay As a workaround, perhaps you could set the values in the actual and expected documents to a known magic value such as ""?

[btiernay]

@hertzsprung I really don't see a difference between (a) ignoring added fields, (b) ignoring array element ordering, and (c) ignoring specific properties. That is to say, if you can make a case for one, you can make a case for all. I could do as you suggest, but then again, I could also do that for (a) and (b).

I could also fork the project and add this feature myself, but I'd much rather contribute to this one as it is already established. Since the need for this feature seems common with many practical applications, why not support it?

The need for (c) comes from the fact that JSON objects do not have an encapsulated equals() method as do classes in languages such as Java. In Java, for instance, one can implement the equals() method to ignore certain fields. In JSON, this must be extrinsic (and thus customizable in assertEquals). This is the motivation here and it seems a reasonable request.

I should also add, FEST assertions FTW :).

[carterpage]

@btiernay It's agreed we need this functionality. We just need to figure out the "right" way to express the functionality. We've been a little slow over the holidays, but we'll be ramping up on features and bugs in the coming weeks. Barring any surprises we'll get this out in a 1.2 in the next month.

[btiernay]

@carterpage Sorry, I guess I misread this thread :) Looking forward to it!