Kotest

Kotest

Produce one high-quality Kotlin test in idiomatic style with Kotest matchers.

Two tracks, one skill:

• Create — write a new test for described behavior.
• Modernize — rewrite an existing Kotlin test to Kotest + idiomatic style.

Pick the track at step 1 based on inputs. The rest of the skill is the same knowledge applied to either starting point.

Non-negotiables

• Do not build broad new test infrastructure inside this skill. If a needed factory / helper / DSL is missing, add a minimal inline fallback and tell the user that extraction may be warranted separately.
• Do not change production code to make a test easier, unless the user asks.
• Modernize track only: preserve assertion semantics exactly. Order sensitivity, nullability, and exception types must not change.
• Follow project overlay (references/project.md) if present — it overrides shared defaults. The overlay is where framework-specific context lives (base classes, test annotations, single-test command, factory locations).

Step 1 — Pick the track

• Modernize if a specific Kotlin test file/class was named, or the user said "improve / rewrite / migrate / modernize this test".
• Create if the user described a behavior to cover, or pointed at production code without an existing test.

If input is a Java test file, this skill does not port it. Suggest the user either (a) describe the behavior so we run the Create track, or (b) manually stage a skeleton Kotlin test for us to run the Modernize track on.

Once the track is picked, follow the corresponding procedure below.

---

Create track

1. Understand the behavior

Read the production code the test will exercise:

• The class/method under test and its collaborators.
• Any validation, exception branches, or ordering guarantees that shape assertions.
• Existing tests nearby — use them as style reference and to avoid duplicating coverage.

If the behavior is ambiguous, ask the user before writing the test.

2. Scan for reusable infrastructure

Before writing, search for what to reuse:

• Object-mother / factory functions (typically *ObjectMother.kt, TestData.kt).
• Kotlin extensions on domain types (toDto(), Iterable<T>.names()).
• Test helpers for setup/teardown or I/O wiring.
• DSLs for object-graph assembly.
• Project base classes for tests (see references/project.md overlay).

If required infra is missing, add a minimal inline fallback or stop and flag it to the user. Do not quietly grow shared infra here.

3. Write the class header

• Pick the test base class or annotations indicated by the project overlay. If there is no overlay, use a plain class with collaborators wired via constructor parameters.
• Follow references/idiomatic-patterns.md for collaborator wiring and naming.

4. Write each test method

For each scenario:

1. Name — backticked sentence: `should reject duplicate tag names`().
2. Arrange — call existing factories; pass only arguments that matter.
3. Act — invoke the behavior.
4. Assert — Kotest matchers (references/kotest-matchers.md).

Assertion style:

• Scalar: actual shouldBe expected.
• Non-null: value.shouldNotBeNull() (smart-casts).
• Collection sizing: list shouldHaveSize n.
• Ordered: list shouldContainInOrder listOf(...).
• Any-order: list shouldContainAllInAnyOrder listOf(...).
• Field projection: items.map { it.name } shouldContainInOrder listOf(...).
• Exceptions: shouldThrow<X> { ... }.message.shouldContain("...").
• Multiple fields on one object: result.apply { ... }.
• Several related checks reporting together: assertSoftly { ... }.

Each assertion must add independent semantic coverage. Do not restate fields already proven by a full-object equality. Do not wrap conditions in assertTrue — use a matcher that describes what the condition means.

5. Run the focused test

Use the single-test command defined in the project overlay. If none is specified, the project's usual test runner with a class-name filter is the right default.

If it fails: first confirm the assertion is correct for the behavior. A green test with the wrong assertion is worse than a red one. If production code is wrong, flag to the user — do not weaken the test.

6. Report

• New file path.
• Which existing infrastructure was reused.
• Any inline fallbacks added (and whether shared extraction is warranted).
• Scenarios covered / intentionally out of scope.
• Exact verification command.

---

Modernize track

1. Read the source test

Record the existing:

• Test framework hooks and annotations — preserve them verbatim.
• Collaborator wiring style (fields vs constructor).
• Any setup/teardown behavior.

These must not drift during modernization. Changing them silently is a bug.

2. Scan for reusable infrastructure

Same scan as the Create track. Existing factories / extensions / helpers are almost always underused in pre-Kotest tests — swap them in during this pass.

3. Modernize structure first, style second

Work in this order — the class must compile between each step:

1. Switch mutable collaborator fields to constructor parameters where the test framework allows it. Keep lateinit var for fields that a framework mechanism requires (consult project overlay).
2. Rename camelCase test methods to backticked sentences, preserving intent: shouldCreateTalk → `should create talk`.
3. Leave assertions untouched for now. Only after compilation is clean, move on to the assertion rewrite.