Skip to content

Conversation

parawanderer
Copy link

@parawanderer parawanderer commented Mar 23, 2025

Hi,

So first of all, thank you for the good work with this library!

It has saved us a lot of time with regards to writing a bunch of crappy chained getX😄

Context

I work on a project where we use this library to validate a bunch of large JSON Objects. Because of these (frankly excessively large and complex) JSON objects, we typically store some large testcase JSON in our test resources folder, and then dynamically manipulate it using json-path/JsonPath to create certain scenarios (e.g. field randomly missing). The reason for doing this is similar to your reason for creating this library -- reducing a bunch of annoying getX/setX chains.

This kind of setup looks like this:

DocumentContext doc = JsonPath.parse(getStringContent("resources/testInput1.json"));
// most standard stuff:
doc.set("$.some.very.very[0].nested.field", 1234567);
doc.delete("$.yet.another.field[*].that.is.nested");
doc.set("$..itemId", UUID.randomUUID()); 


String jsonResult = doSomethingWithTheJson(doc.jsonString());

JSONAssert.assertEquals(
   getStringContent("resources/testOutput1.json"),
   jsonResult,
  // customisations
);

Observe at the bottom we will frequently try to add customisation rules for similar reasons to the input manipulation. For example, we sometimes want to ignore things about some fields, e.g.:

  • a dynamically generated timestamp unix epoch (long), where we want the timestamp to maybe just be later than some time but not match a specific value)
  • a dynamically generated UUID (string), where we just want to be sure the field is a string in the UUID pattern.

We have noted that while it seems that some level of "JSONPath" is supported via wildcards, it doesn't match in a lot of ways that we would have expected, e.g. the type of query like $..itemId in my snippet above is not supported.

And especially complex conditional JSONpath queries as in this section of the Jayway JsonPath project's readme are not supported.

Solution / Proposal

As I noted that this library uses the org.json json implementation, which is one of the one supported by com.jayway.jsonpath (the most popular JSONPath implementation that we use in our setup and that I included in the snippet above), I figured it is quite simple to implement support here for full JSONPath, and hence I went ahead and created this MR to add this support.

The Unit Test Cases and JavaDocs should provide some details about my idea/implementation.

I was wondering what everybody's thoughts are on adding support for this? This would address request #15 which I see is relatively popular


Sidenote: I would also propose looking into whether built-in support can be added for these customisations by IntelliJ Idea via Built-in Language Injections like exists for the Jaway JsonPath library.

This is quite useful and I see they already had an entry for the JSONAssert json strings to be JSON5:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant