Support matching elements in arrays ignoring fields

Hello Kotest developers!

I was wondering if you were planning on developing a feature for assertions to match list elements by ignoring fields. Here is a sample of that kind of assertings with assertJ

assertThat(underTest.findAll())
    .usingElementComparatorIgnoringFields(ConfiguredTask::id.name)
    .containsExactlyInAnyOrderElementsOf(expectedTasks)

Maybe something similar could be implemented in Kotest?

Thank you!

[sksamuel]

I think this is an excellent idea. And we can provide a few comparators out of the box.

[pelletier197]

I have an idea of how it could work. Right now, Kotest has a few matchers with long names. So to follow library naming, the function should be something like

fun <T, C : Collection<T>> C?.shouldContainExactlyInAnyOrderIgnoringFields(expected: C, ignorePrivateFields: Boolean,    property: KProperty<*>, vararg others: KProperty<*>)

That said this becomes really hard to read, and you need to provide overloads for the different configurations (one without ignorePrivateFiels for instance.

What could be great is to pass an optional object comparor. The default comparator would simply do an object equality, which is the current behaviour (using ==).

Something like this:

fun <T, C : Collection<T>> C?.shouldContainExactlyInAnyOrder(expected: C, comparator: ObjectComparator = ObjectComparator.equality()) 

You could therefore, if you want to verify the same thing ignoring fields, do something like this:

actual.shouldContainExactlyInAnyOrder(expected, comparator = ObjectComparator.ignoringFields(ConfiguredTask::id))
// All other equality configuration could be done in chain, making this easy to configure and super readable.
// Example: ObjectComparator.ignoringFields(ConfiguredTask::id, ConfiguredTask::name).ignoringPrivateFields(true)

I understand this is a rather complex concept to implement, and that it should probably not be part of a single merge request to implement this feature, but this is the best way I personally see this could be implemented.

Also, this approach could maybe help reduce the number of functions in the library and allow for more powerful matching.

Let me know what you think about the idea 😃