skip to content

How do you temporarily disable a whole Given block or a single Scenario in a Kotest BDD spec, and what happens to the blocks nested inside it?

level: juniorimportance: should knowfreq 30%

answer

  1. x-prefix on any BDD block
  2. xgiven / xwhen / xthen / xand
  3. xfeature / xscenario
  4. disabled container body never executes - children never register
  5. reported as ignored, not passed

basics

~20 s

Prefix the block with x: xgiven, xwhen, xthen, xand, xfeature, xscenario. Kotest marks that node disabled and never executes its body, so nested blocks are never registered and never appear individually - only the disabled node is reported as ignored.

solid answer

~50 s

Every BDD block in Kotest has an x-prefixed twin: xgiven, xwhen, xthen and xand in BehaviorSpec, xfeature and xscenario in FeatureSpec. Writing xwhen("...") instead of When("...") registers that node as disabled. The important mechanic is that a disabled container's lambda is not executed. Since a Kotest spec builds its tree by running container bodies, nothing inside a disabled container is ever registered - the report shows one ignored node, not a list of skipped children. Compared with commenting the block out, the x-prefix keeps the code compiling (so refactorings and renames still reach it) and keeps the suite honest: the disabled test is visible in the report rather than silently absent. Compared with deleting it, it preserves intent for a known-pending behaviour. Treat x-prefixes as short-lived: they are markers a reviewer can grep for, not a way to park failing tests forever.

code

kotlin · 13 lines
kotlin
class PaymentSpec : BehaviorSpec({
    xgiven("a refunded order") {          // reported once as ignored
        When("refunded again") {          // never registered
            Then("it is rejected") { }    // never registered
        }
    }
    Given("a paid order") {
        When("refunded") {
            Then("the balance returns") { }
            xthen("a receipt email is sent") { }  // this leaf shows as ignored
        }
    }
})

go deeper

for a junior

Know the x-prefix names and that a disabled test shows as ignored rather than passing.

for a middle

Explain why children of a disabled container do not appear: the container body never executes, so nothing registers.

for a senior

Talk about ignored-count hygiene, why x beats commenting out, and when a conditional mechanism is the correct tool instead.

for a principal

Set policy: ignored tests are debt with an owner and an expiry, tracked in CI, never a way to keep a red suite green.

## The mechanism Kotest's BDD styles expose a disabled variant of every block, formed by prefixing an x: - BehaviorSpec: xgiven, xwhen, xthen, xand. - FeatureSpec: xfeature, xscenario. Calling the x-form registers the node with its enabled flag off. The engine reports it as ignored rather than passed or failed, which is exactly the visibility you want: a test that is not running should say so in the report. ## Why nested blocks vanish rather than showing as skipped A Kotest spec's tree is built by executing container bodies. A disabled container is never executed, so the calls inside it never run, so the children are never registered. The result is one ignored entry for the container and no entries at all for its descendants. Candidates often expect the whole subtree to appear greyed out; it does not. If you need each child listed as ignored, disable each child individually instead of the parent. ## Why not just comment it out Commented-out code stops compiling against the production API, so it silently rots: a rename or signature change leaves it stale and the next person deletes it without knowing what it meant. The x-prefixed block still compiles, so IDE refactorings update it and the compiler keeps it honest. It also stays countable - CI reports show ignored tests, and a rising ignored count is a signal a team can act on. ## Discipline around it The x-prefix is a one-character edit, which is its strength and its weakness. Common practice is to require a reason in the block name or a linked ticket in a comment, to grep for x-prefixed blocks in review, and to treat a growing ignored count as debt. A permanently disabled test is worse than a deleted one: it costs reading time and gives false comfort that the behaviour is covered. ## Relationship to other ways of not running a test Kotest has other mechanisms for conditional execution - test configuration flags and its own tag system - which are the right tools when a test should run in some environments and not others. The x-prefix is different in intent: it is unconditional and hardcoded in source, meant for work in progress or a known-broken behaviour with a ticket. Choosing the x-prefix for something environment-dependent is a smell, because it disables the test everywhere including the environment where it would pass. ## Quick checklist - x-prefix exists for every BDD block, including containers. - A disabled container body is not executed, so children never register. - The report shows the node as ignored, not passed. - Prefer it to commenting out; prefer deletion or a ticket to leaving it forever.

  • If you disable a given but want each nested then to still appear as ignored in the report, what do you do?
    Disable the leaves individually with xthen instead of disabling the parent. Because a disabled container's body never executes, its children are never registered and cannot be listed; only nodes you explicitly register as disabled can show up as ignored entries.

saying these in an interview costs you the question

  • Expecting every nested block under an xgiven to appear as skipped
  • Saying a disabled test still runs but its failure is suppressed
  • Using the x-prefix for environment-dependent tests instead of Kotest's conditional or tagging mechanisms
  • Preferring commented-out blocks because 'it is the same thing'

context

resolving links…