Possible confusion between shouldContainExactlyInAnyOrder overloads

[nicopico-dev]

Using Kotest 4.6.3 with Kotlin 1.5.31

There is a possible confusion for user between these overloads of shouldContainExactlyInAnyOrder() assertion:

infix fun <T, C : Collection<T>> C?.shouldContainExactlyInAnyOrder(expected: C): C?
fun <T, C : Collection<T>> C?.shouldContainExactlyInAnyOrder(vararg expected: T): C? 

When using an optional collection for expected, Kotlin will use the vararg parameter implementation, which will fails as it checks if expected is an item in the actual collection instead of comparing both collections.

Allowing optional collection would likely prevent this issue

infix fun <T, C : Collection<T>> C?.shouldContainExactlyInAnyOrder(expected: C?): C?

Example

val actual: List<String> = listOf("A", "B", "C")
val expected: List<String>? = listOf("A", "B", "C")
actual.shouldContainExactlyInAnyOrder(expected)
// => ERROR: Collection should contain [["A", "B", "C"]] in any order, but was ["A", "B", "C"]

val actual: List<String> = listOf("A", "B", "C")
val expected: List<String> = listOf("A", "B", "C")
actual.shouldContainExactlyInAnyOrder(expected)
// => OK

[jschneidereit]

Might need to do the ...(first: T, second: T, vararg rest: T) trick here if we add that collection overload

[jschneidereit]

Now that I'm more awake, what is the use case for having an optional expected? That seems kinda unlikely 🤔

[nicopico-dev]

I was bitten by this in a test that is more or less like this:

val expectedParameters: Map<String, List<String>>
val actualParameterValues: List<String>

actualParameterValues.shouldContainExactlyInAnyOrder(expectedParameters["SomeParameter"])

The issue is that expectedParameters["SomeParameter"] is of type List<String>?, so the assertion did not compare the lists as I would have expected, and I couldn't understand what was happening for some time.

It just seems confusing to me that the behavior can change so much just by making a type optional

[sksamuel]

The real solution would be to inform the compiler not to promote T to Any but alas we can't do that yet so we'll need a work around.
Thanks for the bug report, this is indeed a gotcha.

[sksamuel]

I created this a while ago, please upvote: https://youtrack.jetbrains.com/issue/KT-49194