Option TREAT_NULL_VALUES_AS_ABSENT only works unidirectional

[tram98]

Describe the bug

I am using Version 5.0.0 (but 4.1.1 is affected, too) with junit 5.10.0:

<dependency>
    <groupId>net.javacrumbs.json-unit</groupId>
    <artifactId>json-unit-assertj</artifactId>
    <version>5.0.0</version>
    <scope>test</scope>
</dependency>

Using the Option TREATING_NULL_AS_ABSENT only works when the expected JSON omits a key that is null on the actual object.

The other way around, null values are not considered equal to absent ones.

Below example should demonstrate what I mean:

// this works
assertThatJson("{\"test\":{\"a\":1, \"b\": null}}")
    .when(TREATING_NULL_AS_ABSENT)
    .isEqualTo("{\"test\":{\"a\":1}}");


// this fails
assertThatJson("{\"test\":{\"a\":1}}")
    .when(TREATING_NULL_AS_ABSENT)
    .isEqualTo("{\"test\":{\"a\":1, \"b\": null}}");

// org.opentest4j.AssertionFailedError: JSON documents are different:
// Different keys found in node "test", missing: "test.b", 
// Expected :{"a":1,"b":null}
// Actual   :{"a":1}

I am open to submitting a PR for this, if you will review and merge it.

[lukas-krecan]

Hi, thanks for feedback. It's intentional, the assumption is that the expected value is under your control so you don't just don't have nulls there. Can you please describe your use-case?

[tram98]

Hi, thanks for feedback. It's intentional, the assumption is that the expected value is under your control so you don't just don't have nulls there. Can you please describe your use-case?

Hi @lukas-krecan,

Thanks for your quick response!

I am using the library inside a unit test that determines if a serialised JSON payload matches another payload loaded from a file.

Unfortunately, there are cases where inconsistencies exist regarding explicit null values and field absence.

That is true for both the expected and the actual JSON, so just swapping the values does not solve my problem in the long term.

[tram98]

Thanks for this library, by the way. So far, I has been really helpful :)

[lukas-krecan]

In that case I think DifferenceListener might help you. And it might make sense to use directly the Diff class. It's kinda internal but people are using it for things like your use-case.

[tram98]

I will have a look, thanks.

If your assumption is that one can control the expected value, I'd consider stating this explicitly in the documentation of the option value. I spent an hour trying to find the reason why the null value was still being marked as missing.

Are you open to introducing another option to support the other way round, too?