Hey everyone! do we have an 'ignoring' assertion which works on Collections? I want to compare two ...

# kotest

[Shervin]

Hey everyone!

do we have an 'ignoring' assertion which works on Collections?
I want to compare two lists, ignoring the id of their content.
Imagine:
data class Person (val id: String, val name: String)

I expect sth like the following:
listOf(Person("0", "Tom")).shouldBeEqualToIgnoringFields(listOf(Person("1", "Tom")), Person::id)

do we have this?
🙏

[Emil Kantis]

val tom = Person("1", "Tom")
val persons = listOf(Person("0", "Tom"))

persons.forOne {
  it.shouldBeEqualToIgnoringFields(tom, Person::id)
}

[Shervin]

hm,
yeah it works, but what if I want to assert List A is equal to List B ? ignoring a field on the Item

[Shervin]

I'm looking for sth like:

shouldContainAllIgnoringFields

that would ideal for me.
one liner assertion for comparing Collections while ignoring a field.

[Shervin]

Hey @sam!
Is there a reason that we don't have this? or is it a possible assertion that we can have?

[sam]

Yeah can add it, would welcome a PR.

[Shervin]

I will create a PR for this shortly

[Davio]

How about some zipped assertion with a custom matcher like AssertJ has?

[sam]

link ?

[Davio]

https://joel-costigliola.github.io/assertj/core-8/api/org/assertj/core/api/AbstractIterableAssert.html#zipSatisfy-java.lang.Iterable-java.util.function.BiConsumer-

[Davio]

Could be quite a flexible approach

[sam]

could you do this with just listA.zip(listB).forAll { (a,b) -> }

[Emil Kantis]

Would need something like https://arrow-kt.io/docs/0.12/apidocs/arrow-core-data/arrow.core/kotlin.collections.-iterable/pad-zip.html to handle differing lengths

[Shervin]

zipSatisfy compares 1 to 1, right?
where as in Contains items might not be in the exact order

[sam]

I think zipSatisfy is just zipping two lists together and then comparing each pair of elements in turn against some assertions. So that's just regular zip plus a Kotest inspector ( I think !)

[Davio]

Yeah my assumption was that the lists have the elements in the same order

[Shervin]

that can also be of use, but in my case I want to be flexible with the orders of the items. I don't want to rewrite the test every-time I change the order returned in the api 😄

[Shervin]

Thanks for the suggestion!
didn't know zipSatisfy exist!

[Shervin]

Hey @sam!
I finally found some time to work on this,


I have a question about principles that I need to follow if you could clarify please:

I've added:

fun <T : Any> Iterable<T>.shouldContainAllIgnoringFields(...)

to support comparing Iterables ignoring field(s).
Now my question is may I re-use our current

beEqualToIgnoringFields

that we have, to compare the items in the list?
In other words, can a matcher re-use another matcher?

🙏

[Davio]

I wouldn't see why not, I think this makes more sense than writing manual assertions each time

[Shervin]

Thanks @Davio
I thought so