Support for ignoring unknown keys in JSON asserts

[Kantis]

Closes #2298

Added new matchers shouldEqualJsonIgnoringUnknown and
shouldNotEqualJsonIgnoringUnknown. Supports for specifying all
other flags that the previous json matcher supported.

The existing compare method already supported the use-case quite easily,
and had good error messages for possible validation errors.

Unknown keys can only exist in object nodes. The scenarios currently
covered by tests are:

• Actual contains a key not specified in expected - key is ignored
• Actual contains a key specified in expected - key is compared
• Actual is missing a key specified in expected - matcher error occurs

Since comparison happens recursively, I also added tests to make sure
the ignoring is in effect deeper in the structure as well.

Todo

• add in changelog
• update docs

[Kantis]

Will add documentation as well.

Do you think it would make sense to put it between shouldEqualJson and shouldContainJsonKey at https://kotest.io/docs/assertions/json-matchers.html? It feels closely related to shouldEqualJson.

[sksamuel]

Is this what Lenient mode is meant to do ?

[Kantis]

Is this what Lenient mode is meant to do ?

As a user, I would prefer to have strict types while comparing if possible, but I agree it would feel natural and this change might make the API too verbose? Perhaps it might be worth introducing something like this:

class CompareOptions(
   build: CompareOptions.() -> Unit
) {
   var ignoreKeyOrder: Boolean = false
   var coerceTypes: Boolean = false
   var ignoreUnknownKeys: Boolean = false

   init {
       build()
   }
}

fun String.shouldEqualJson(expected: String, options: CompareOptions.() -> Unit): Unit =
   TODO()

fun x() {
   "actual".shouldEqualJson("expected") { ignoreKeyOrder = true }
}

it loses out on the infix fun though, which is a shame..

[sksamuel]

Oh that's right, strict vs lenient is about the types. Maybe we should document that since I had forgotten myself and I wrote it :) Anyway, I think adding another enum works. FieldComparision or something.

…

On Mon, 14 Jun 2021 at 17:14, Emil Kantis ***@***.***> wrote: Is this what Lenient mode is meant to do ? As a user, I would prefer to have strict types while comparing if possible, but I agree it would feel natural and this change might make the API too verbose? Perhaps it might be worth introducing something like this: class CompareOptions( build: CompareOptions.() -> Unit ) { var ignoreKeyOrder: Boolean = false var coerceTypes: Boolean = false var ignoreUnknownKeys: Boolean = false init { build() } } fun String.shouldEqualJson(expected: String, options: CompareOptions.() -> Unit): Unit = TODO() fun x() { "actual".shouldEqualJson("expected") { ignoreKeyOrder = true } } it loses out on the infix fun though, which is a shame.. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2303 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFVSGRSZPQ6MXPUM67ZGSTTSZ5OBANCNFSM453NZHRA> .

[Kantis]

Something like this? And we replace the ignoreUnknownKeys boolean with this?

enum class FieldComparison {
   /** Verifies all expected key-values match, and that no extra keys exist in the actual */
   ComparingAll,
   /** Verifies all expected key-values match, ignoring keys in actual that are not defined in expected*/
   ComparingExpected
}

[sksamuel]

Something like this? And we replace the ignoreUnknownKeys boolean with this?

enum class FieldComparison {
   /** Verifies all expected key-values match, and that no extra keys exist in the actual */
   ComparingAll,
   /** Verifies all expected key-values match, ignoring keys in actual that are not defined in expected*/
   ComparingExpected
}

enum class FieldComparison {
   /** Verifies all expected key-values match, and that no extra keys exist in the actual */
   Exact,
   /** Verifies all expected key-values match, ignoring keys in actual that are not defined in expected*/
   IgnoreExtra
}

Maybe something like that ?

[sksamuel]

Is this ready for final review ?

[Kantis]

@sksamuel aye, it should be.

[sksamuel]

Sorry is this still waiting on me? If so can we fix the conflicts and I will review.

[Kantis]

@sksamuel should be ready now, I think the failing test is flaky.