{
  "id": 7744566,
  "title": "BDD in Kotlin: The Options, and How to Choose",
  "url": "https://urgent.news/2026/09/16/bdd-in-kotlin-the-options-and-how-to-choose",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-16T08:27:34.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/paul-brooks/bdd-in-kotlin-the-options-and-how-to-choose-3mha"
  },
  "original_language": "en",
  "account": "This is a biased guide on Behavior-Driven Development (BDD) in Kotlin, focusing on the options available and how to choose the right one. The author started writing acceptance tests on the JVM in 2009, trying different tools like Concordion, Cucumber, Yatspec, and eventually creating their own tool, Kensa. The core idea is to write tests as sentences, eliminating the need for feature files, step definitions, and glue code.\n\nThe decision point for choosing a BDD framework is not based on syntax comparison, but rather on who reads the output and whether they need to. If developers read the output, there's no need to add a framework; Kotest or JUnit with well-named tests can handle everything. However, if testers, analysts, or product owners are the target audience, an artefact is required for them to understand the tests without knowing Kotlin.\n\nCucumber and JBehave read scenarios in Gherkin and match step definitions to the text. The feature file is readable by anyone and can exist before the code, but the cost is maintaining three things instead of one, as text in feature files can't be refactored by IDEs. Kotest's BehaviorSpec provides the same functionality as Cucumber and JBehave, with refactoring support and a test result output.\n\nSpek is a Kotlin-native, Gherkin-shaped DSL that works well with Kotlin-native projects. JGiven reads readable text derived from method names, keeping refactoring in sync with the test scenarios. Serenity BDD is a close tool to Kensa, generating a detailed report aimed at testers with screenshots and results by requirement. However, it comes with a substantial framework, most of which is WebDriver and Screenplay, and produces a static report once written.\n\nConcordion, the initial tool the author used, writes the specification as a document for the reader, which is a different artefact compared to Gherkin. The ticket's Given/When/Then gets implemented as the test, in the same words, carrying the reference to the ticket. The ticket already exists in a shared, readable location, so creating a second copy of it in source code is unnecessary. The focus should be on keeping the specification and test in agreement, rather than maintaining three separate artefacts.",
  "summary": "I've been writing acceptance tests on the JVM since 2009. Concordion first, then Cucumber on the teams around me, then Yatspec, and eventually I wrote my own. Yatspec's trick was that it read the test method itself. You wrote: given ( orchestration . sends ( anOrder )); and the report showed: Given orchestration sends an order No feature file, no step definitions, no glue. The test was the…",
  "key_points": [
    "Choose BDD framework based on audience: developers read output, testers/analysts need artefact.",
    "Spek provides refactoring support and test result output for Kotlin-native projects."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}