Kotest's `withData` generates test names from the input values. What mechanisms does Kotest give you to override that generated name, and when would you pick each one?

## The default and why you override it `withData` (package `io.kotest.datatest`, artifact `kotest-framework-datatest`) registers one test per element and derives each name from the value: `WithDataTestName` first, then an `@IsStableType`-annotated class's `toString()`, then a data class's generated `toString()`, otherwise a type-derived fallback. The default is fine for small data classes. It stops being fine when: - the type is not yours (a third-party request/response object, a JDK type wrapper) and has no useful `toString()`; - the data class carries a large or binary property — a byte array, a full JSON body, a 40-field aggregate — so the generated name is a paragraph or contains `[B@1f2a3b`; - the name you want is a *description of the case* ("expired token", "cart over free-shipping threshold"), which no `toString()` will ever produce; - the same input type is reused in several specs where different aspects matter. ## Mechanism 1 — `WithDataTestName` ```kotlin class Scenario(val id: String, val body: ByteArray) : WithDataTestName { override fun dataTestName(): String = "scenario $id" } ``` The interface has a single method, `dataTestName(): String`, and it wins over every other rule. Use it when the type is a first-class test fixture in your codebase and there is one obviously right label. The advantage is that every call site gets good names for free and nobody has to remember to pass a lambda. The cost is that the naming decision is baked into the type. ## Mechanism 2 — `@IsStableType` ```kotlin @IsStableType class Money(val cents: Long) { override fun toString(): String = "$${cents / 100}.${cents % 100}" } ``` This does not supply a name; it grants **permission**. It tells Kotest "this class's `toString()` is hand-written and deterministic — trust it". Without the annotation, a non-data class falls back to the type-based name even if you did override `toString()`. Use it when the class already prints itself well and you do not want a second, parallel naming method. ## Mechanism 3 — the `nameFn` overload ```kotlin withData( nameFn = { "HTTP ${it.status} -> retry=${it.shouldRetry}" }, responses, ) { case -> ... } ``` The first parameter is a `(T) -> String`. It is available on the vararg, collection and sequence forms. This is the workhorse for third-party types and for trimming a noisy `toString()` down to the one or two fields that identify the case. It also keeps the naming local, so two specs can label the same type differently. ## Mechanism 4 — the map overload ```kotlin withData( mapOf( "empty cart" to Cart(), "single item under threshold" to Cart(item(5_00)), "two items over threshold" to Cart(item(60_00), item(10_00)), ), ) { cart -> shipping(cart) shouldBe expected(cart) } ``` The map keys become the test names **verbatim** — no derivation, no truncation. This is the most readable option when the cases are a hand-curated list of named scenarios rather than a mechanically generated set, because the name is a specification sentence, not a dump of the input. The trade-off: the map is ordered by whatever `Map` implementation you pass, so use `mapOf`/`LinkedHashMap` if you care about report order, and remember duplicate keys silently collapse in a map literal — two cases with the same key means you lose one *before* Kotest ever sees them. ## Choosing between them A workable rule: - Input is a small data class you own and its `toString()` reads well → do nothing. - Input is yours, has one canonical short label, used in many specs → `WithDataTestName`. - Input is yours, already prints well, not a data class → `@IsStableType`. - Input is third-party, or the name should describe intent rather than content → `nameFn`. - Cases are a curated list of named scenarios → the map overload. ## What good names buy you Generated names are identifiers, not decoration. They are what the IDE re-runs, what name-based test filters match, what a CI report shows a reviewer, and what a flaky-test dashboard groups on. Names must therefore be **stable** (same input, same name, every run), **unique** within their scope (or Kotest's duplicate-name handling starts appending indexes), and **short enough to read** in a report column. All four mechanisms exist to let you satisfy those three properties whatever the input type looks like.