Kotest has shouldBeSorted plus matchers such as shouldBeSortedWith, shouldBeMonotonicallyIncreasing and shouldBeStrictlyIncreasing. What does each assert, and what are the traps in asserting sortedness?

## What the matchers assert Kotest's ordering matchers all work on collections of `Comparable` elements (or with an explicit comparator) and check the relationship between adjacent elements. ```kotlin listOf(1, 2, 2, 3).shouldBeSorted() // passes: ties allowed listOf(1, 2, 2, 3).shouldBeMonotonicallyIncreasing() // passes listOf(1, 2, 2, 3).shouldBeStrictlyIncreasing() // FAILS: 2 == 2 listOf(3, 2, 1).shouldBeMonotonicallyDecreasing() // passes listOf(3, 2, 1).shouldBeSortedWith(compareByDescending { it }) // passes ``` **Natural versus custom ordering.** `shouldBeSorted()` uses the element type's own `compareTo`. As soon as the ordering is domain-specific — descending, by a property, multi-key — you need `shouldBeSortedWith`, which accepts a `Comparator`. Kotlin's `compareBy`, `compareByDescending` and `thenBy` build those readably: ```kotlin tasks.shouldBeSortedWith(compareBy<Task> { it.dueDate }.thenBy { it.priority }) ``` **Ties.** The monotonic/strict pair exists precisely to make the tie question explicit. "Monotonically increasing" means never decreasing — `[1, 1, 2]` is fine. "Strictly increasing" means every step goes up — `[1, 1, 2]` fails. Choosing the strict variant is how you assert "ordered *and* no duplicates" in a single matcher, which is exactly right for generated sequence numbers, version counters, or event timestamps that must advance. ## Trap 1: vacuous truth Every ordering matcher is a statement about *adjacent pairs*. An empty collection has none; a single-element collection has none. So: ```kotlin emptyList<Int>().shouldBeSorted() // passes listOf(42).shouldBeStrictlyIncreasing() // passes ``` A test whose query silently returned nothing will happily go green. Always pair the ordering assertion with a size or non-empty assertion: ```kotlin results shouldHaveSize 3 results.shouldBeSortedWith(compareBy { it.createdAt }) ``` This is the single most valuable point to make in an interview about this family, because it is a real way tests silently stop testing. ## Trap 2: sortedness under-specifies Ordering matchers say nothing about *which* elements are present. `[1, 5, 9]` and `[2, 3, 4]` are both sorted. If your test knows the expected contents, asserting the expected list with `shouldContainExactly` covers both contents and order in one assertion and produces a better failure report. Ordering matchers earn their keep when the contents are genuinely not predictable — results from a real database, generated data, a property-based test — but the *ordering* is contractual. That is the honest use case: "whatever came back, it must be ordered by score descending". ## Trap 3: comparator/equality mismatch A comparator inconsistent with `equals`, or one that orders on a nullable or non-total key, produces confusing outcomes. Sorting by a property whose values collide means "sorted" is satisfied by several different arrangements, so an ordering assertion may pass for output your users would call wrong. If tie-breaking matters to the contract, put the tie-breaker in the comparator (`thenBy`) so the assertion actually pins it. ## Trap 4: Comparable requirement `shouldBeSorted()` needs a `Comparable` element type. For domain objects that are not comparable — and most should not be — the compiler pushes you to `shouldBeSortedWith`, which is the right outcome: the ordering belongs in the test's comparator, not bolted onto the domain type just to make an assertion compile. Adding `Comparable` to a domain class purely for testing is a smell worth calling out. ## Putting it together ```kotlin val page = repository.topScores(limit = 10) page shouldHaveSize 10 // not vacuous page.shouldBeSortedWith(compareByDescending { it.score }) // the contract page.map { it.userId }.shouldNotContainDuplicates() // no user twice ``` Three assertions, each pinning a distinct property of the contract, none of them redundant. ## Interview-ready summary Natural order versus comparator; ties allowed (monotonic/sorted) versus forbidden (strict). Empty and single-element collections pass everything vacuously, so assert size too. And prefer `shouldContainExactly` on an expected ordered list whenever the contents are known — reserve ordering matchers for the case where only the ordering, not the content, is contractual.