Kotest's AnnotationSpec lets you write tests as annotated methods instead of a DSL lambda. How does Kotest discover and name those tests, which lifecycle annotations does it provide, and what do you give up compared with Kotest's lambda-based flat styles?

## The odd one out Every other Kotest spec style registers tests by **executing code**: you pass a lambda to the spec constructor (or fill an `init` block) and the calls inside it build a test tree. **AnnotationSpec** does not. You extend it with parentheses — `class CalculatorTest : AnnotationSpec()` — and declare ordinary methods; Kotest inspects the class **reflectively** and turns each annotated method into a test case. That single difference explains every capability and every limitation of the style. ## The annotations The annotations are Kotest's own, declared as **nested annotation classes on `AnnotationSpec`**, so after importing the spec you write them unqualified: - `@Test` — marks a method as a test. - `@Test(expected = IllegalStateException::class)` — the test passes only if a matching exception is thrown. - `@Ignore` — the method is skipped. - `@BeforeEach` / `@AfterEach` — run around **each** test method in the spec. - `@BeforeAll` / `@AfterAll` — run **once** around all tests in the spec. They are Kotest's annotations, even though they intentionally mirror the shape people already know from annotation-driven frameworks. Importing a same-named annotation from elsewhere is the classic first-day mistake: the class compiles, the run finds nothing, and the spec reports zero tests. ```kotlin class CalculatorTest : AnnotationSpec() { private lateinit var calc: Calculator @BeforeEach fun setUp() { calc = Calculator() } @Test fun `adds two positive numbers`() { calc.add(2, 3) shouldBe 5 } @Test(expected = ArithmeticException::class) fun dividesByZero() { calc.divide(1, 0) } @Ignore @Test fun notImplementedYet() { } } ``` ## Naming The test name is the **method name**. Kotlin's backtick syntax rescues readability — `` fun `adds two positive numbers`() `` reports as *adds two positive numbers* — but the name is still bound to an identifier, which means it must be unique within the class (the compiler enforces that for you, which is a small silver lining versus a flat string namespace) and cannot be computed. There is no way to say "name this test after the row of data it is running", because there is no code producing the registration. ## What the reflective model costs you 1. **No containers, no nesting.** Every test method is a root-level leaf. There is no grouping vocabulary at all. 2. **No `.config(...)`.** The lambda styles let you write `test("x").config(timeout = ...) { }` or `"x".config(invocations = 3) { }`. A method has nowhere to hang that builder; your per-test knobs are the annotation parameters — `expected` and `@Ignore` — plus whatever spec-level configuration you set by overriding spec properties. 3. **No dynamic registration.** In a DSL style the body is code, so a loop can register N tests. Here the test set is exactly the set of annotated methods in the compiled class. Data-driven testing therefore has to move inside a single method's body, where the failure of any row fails the one enclosing test rather than reporting per-row. 4. **Weaker integration with name-derived features.** Anything driven by readable, structured test paths — grouped report output, path-based filtering — gets less to work with when every name is an identifier at the root. ## What you keep The test bodies are still **suspending**, so suspend calls work directly; Kotest's matchers, lifecycle callbacks defined at spec level, and the rest of the framework apply normally. AnnotationSpec is a first-class Kotest spec, not a compatibility shim bolted on the side: it participates in the same lifecycle and the same test engine as the other styles. ## Why it exists Two honest reasons. First, **familiarity** — a team whose muscle memory is annotated test methods can adopt Kotest's matchers, property testing and extensions on day one without also learning a DSL. Second, **conversion friction**: an existing annotation-style test class can be brought under Kotest with mechanical changes (change the superclass, swap the annotation imports, rename lifecycle methods) rather than a rewrite, after which individual classes can be moved to a DSL style at leisure. The standing advice in practice is that AnnotationSpec is a **destination for old tests, not for new ones**: new specs are written in a style with containers and string names, because that is where Kotest's expressiveness lives. ## Interview traps Being asked "can I generate tests from a loop in AnnotationSpec?" is a trap for the reflective model — the answer is no, because there is no registration lambda to run. Being asked "which `@Test` did you import?" is a trap for the nested-annotation detail.