Allow field values to be ignored by specifying a JSON path

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.

Any idea what this might look like to a programmer?

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.

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.

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!

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?

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?

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.

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 😃

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");

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

@carterpage

@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 ""?

@hertzsprung

@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 :).

@btiernay

@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.

@carterpage

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

I wonder if a more flexible approach might be to allow the developer to specify a wildcard sequence in the character string. The wildcard sequence could be an optional final argument to the assertEquals() method, or a component of the proposed JSONConstraint class.

So let's say you want to check the contents of a response, but you're not interested in the exact value of the (DB-generated) user id:

String expected = "{id:**,name:\"Joe\",friends:[{id:**,name:\"Pat\",pets:[\"dog\"]},{id:**,name:\"Sue\",pets:[\"bird\",\"fish\"]}],pets:[]}";
String wildcard = "**";

JSONAssert.assertEquals( expected, actual, false, wildcard );

The advantages of this approach are:

Potentially less error-prone. You can simply compose your expected document with wildcards, instead of having to compose one or more ignore-paths, and cross check them against the document.
More flexible. Suppose you have a collection of elements, and you want to precise-match a field on some elements of the collection, but wild-card match the same field on other elements of the connection. You can do that with wildcard matching, but not with the ignore-path approach.

Hi,

Apologies for asking same question again.

I have same requirement and have been googling from long time. i have read the comments but couldnt understand if the issue is fixed, or trying with some solution?

if fixed, can some one please let me know how to ignore fields.

@Naveen1836

@Naveen1836 : Pls see my reply (two posts above yours). I was able to implement something that way

@praveen133t

@praveen133t:
Can you send me the code, i mean class which you are extending that code to naveenavula1989@gmail.com

Anyone want to submit a PR for partial ignore? I can add to 1.4.1.

Implements partial ignore skyscreamer#15

@carterpage

Partial compare is a must have feature in the world of REST APIs. If we can merge this in time for 1.5.1, it would be very useful. @carterpage

@ittiel

I found my way here looking for partial ignore but after reading @ittiel's solution I implemented my own comparator that looked for specific place holder tokens and did a different type of value comparison.

Trying validate this:

Expected: {"accountNumber": "<UUID>"}
Actual: {"accountNumber": "b14759a9-2840-44f9-84cd-2814a2069261"}

package com.cloudbank.account.endtoend;

import org.json.JSONException;
import org.skyscreamer.jsonassert.JSONCompareMode;
import org.skyscreamer.jsonassert.JSONCompareResult;
import org.skyscreamer.jsonassert.comparator.DefaultComparator;

import java.util.UUID;

public class DynamicValueTokenComparator extends DefaultComparator {

    public DynamicValueTokenComparator(JSONCompareMode mode) {
        super(mode);
    }

    @Override
    public void compareValues(String s, Object o, Object o1, JSONCompareResult jsonCompareResult) throws JSONException {

        // --- ! This could be a stack of things looking at tokens like <UUID> <DATE> etc

        // A dynamic UUID is expected
        if (o.toString().equals("<UUID>")) {
            // If yes then the corresponding UUID must be valid
            try {
                UUID.fromString(o1.toString());
            } catch (IllegalArgumentException e) {
                throw new JSONException("Invalid UUID for field " + s);
            }

            // Return - don't apply default value checking
            return;
        }

        super.compareValues(s, o, o1, jsonCompareResult);
    }
}

In the test:

JSONAssert.assertEquals(json, response.getBody(), new DynamicValueTokenComparator(JSONCompareMode.NON_EXTENSIBLE));

Maybe it will be helpful: in my Spring controller tests I've made workaround for this problem: https://stackoverflow.com/a/47896806/548473

+1 for this feature - I have a requirement for this feature

I recently found this library JsonUnit which has the exact functionality check it out

I use this library and created an extended version for a custom Partial JSON assertion that I needed. I have that jar created for updated library in this location. Feel free to use it and to give me feedback on that.

+1 for this feature. Any progress on this feature ?

Hi All, I am not getting dependency for JAConstraint

+1 for this feature

Hi, I have implemented support for this in this MR: #201

Curious to see if anybody had any feedback or suggestions on it?

Navigation Menu

Repository navigation

Allow field values to be ignored by specifying a JSON path #15

41 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow field values to be ignored by specifying a JSON path #15

Description

Activity

carterpage commented on Oct 16, 2012

hertzsprung commented on Nov 4, 2012

carterpage commented on Nov 6, 2012

hertzsprung commented on Nov 6, 2012

ibrahimover commented on Nov 29, 2012

hertzsprung commented on Nov 29, 2012

ibrahimover commented on Nov 30, 2012

hertzsprung commented on Nov 30, 2012

carterpage commented on Dec 5, 2012

btiernay commented on Jan 13, 2013

hertzsprung commented on Jan 13, 2013

btiernay commented on Jan 13, 2013

carterpage commented on Jan 27, 2013

btiernay commented on Jan 28, 2013

cepage commented on Jan 30, 2013

41 remaining items

Naveen1836 commented on Oct 20, 2016

praveen133t commented on Oct 20, 2016

Naveen1836 commented on Oct 20, 2016

carterpage commented on Oct 30, 2016

bkdonline commented on Jul 18, 2017

benwaine commented on Nov 17, 2017

JavaOPs commented on Dec 19, 2017

SrikarNanduri commented on Jan 22, 2018

SrikarNanduri commented on Jan 23, 2018

arundharmar commented on Feb 3, 2018

VegetaPn commented on May 22, 2019

Ripul89 commented on Jul 3, 2019

dilipsonu commented on Feb 5, 2020

parawanderer commented on Mar 23, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions