In Kotest, what exactly is the difference between shouldContainExactly, shouldContainExactlyInAnyOrder and shouldContainAll — particularly with respect to ordering, size and duplicate elements?

## The ladder Kotest's collection matchers differ along three axes: does order matter, does size matter, do duplicates matter. Placing each matcher on those axes is the whole question. | Matcher | Order | Size/extras | Duplicates | |---|---|---|---| | `shouldContainExactly` | must match | must match | counted, positionally | | `shouldContainExactlyInAnyOrder` | irrelevant | must match | counted | | `shouldContainAll` | irrelevant | extras allowed | ignored | | `shouldContain` | irrelevant | extras allowed | ignored (single element) | ## shouldContainExactly This is a full positional comparison — conceptually the same statement as `shouldBe` on two lists, but expressed as a collection assertion and reported as one. Same length, same elements, same order. ```kotlin listOf(1, 2, 3) shouldContainExactly listOf(1, 2, 3) // passes listOf(1, 2, 3) shouldContainExactly listOf(3, 2, 1) // fails: order listOf(1, 2) shouldContainExactly listOf(1, 2, 2) // fails: size ``` When it fails, Kotest reports the divergence — which elements are missing from the actual collection and which are present but unexpected — rather than just printing two lists and leaving you to diff them. ## shouldContainExactlyInAnyOrder The most misunderstood one. It is a **multiset** (bag) comparison, not a set comparison. Two collections match when they have the same size and every element occurs the same number of times in each. ```kotlin listOf(1, 2) shouldContainExactlyInAnyOrder listOf(2, 1) // passes listOf(1, 1, 2) shouldContainExactlyInAnyOrder listOf(1, 2, 2) // FAILS listOf(1, 1, 2) shouldContainExactlyInAnyOrder listOf(1, 2) // FAILS (size) ``` The second example is the one candidates get wrong: both sides contain exactly the values {1, 2}, so anyone thinking "set comparison" expects a pass. Duplicate counts differ, so it fails. That is a feature — a de-duplication bug in the code under test should not slip past an "any order" assertion. If you truly want set semantics, convert explicitly: `actual.toSet() shouldContainExactlyInAnyOrder expected.toSet()`, and be aware you have just stopped testing duplicates at all. ## shouldContainAll A containment/subset assertion. Every named element must be present at least once; the actual collection may contain anything else besides. ```kotlin listOf(1, 2, 3, 4) shouldContainAll listOf(1, 3) // passes listOf(1, 1, 1) shouldContainAll listOf(1) // passes ``` This is a genuinely weak assertion, and that is sometimes right — asserting that an audit log contains two specific events without pinning the rest. But it is often used as a way to make a flaky test green, and then the test no longer detects extra, duplicated or wrongly ordered output. ## Choosing the right strength The rule is: **assert the strongest property the contract actually guarantees.** - A repository method documented as returning results ordered by creation date: `shouldContainExactly`. If you weaken it to `InAnyOrder`, the ordering bug ships. - A method returning a `Set`, or results from a source with no defined iteration order: `shouldContainExactlyInAnyOrder`. Using `Exactly` here buys you a test that passes on your machine and fails in CI. - Only a couple of elements are part of this test's contract and the rest belong to other tests: `shouldContainAll`, with the test name saying so. A common anti-pattern is the weak pair: `result shouldHaveSize 3` plus `result shouldContain expected`. Together those pass for many wrong results. One `shouldContainExactly` or `shouldContainExactlyInAnyOrder` is both shorter and strictly stronger. ## Vararg and collection forms All of these come in both forms — `shouldContainExactly(1, 2, 3)` with varargs and `shouldContainExactly(listOf(1, 2, 3))` as an infix call with a collection. The vararg form reads better inline; the infix form is handy when the expected value is already a variable. ## Interview-ready summary Exactly = order + size + duplicates. InAnyOrder = size + duplicates, no order (multiset, *not* set). All = subset, extras and duplicates ignored. Choose by what the code under test actually guarantees, and never weaken a matcher just to stop a test flaking — that is a signal the ordering is undefined, which is information the assertion should record honestly.