Kensa

Kensa is a BDD testing framework for Kotlin and Java. Write Given-When-Then tests directly in code — no Gherkin files, no step definitions. Kensa parses your test source at runtime to produce rich HTML reports and sequence diagrams.

Check out the documentation for quickstarts, API reference, and examples. See the roadmap for the road to 1.0 and what follows it.

Write this…	…get this

BDD in Kotlin and Java — without Gherkin

Most JVM testing tools produce output for the person who wrote the test. Kensa produces output for everyone else. Testers, analysts and product owners read a Kensa report to get an honest account of what an application actually does — and it is honest because it is generated from the test source that ran, not from a document maintained alongside it.

That is the whole idea: keep the readable specification, drop the Gherkin file, the step definitions and the drift between them.

New to BDD on the JVM, or weighing the options? Start with BDD in Kotlin: the options, and how to choose.

Features

• Code-first BDD — Given-When-Then structure in plain Kotlin/Java; no external DSL files
• HTML reports — generated directly from test source, always in sync with the code
• Sequence diagrams — visualise interactions between actors captured during test execution
• Framework support — JUnit 5 & 6, Kotest, TestNG
• Assertion libraries — Kotest, AssertJ, Hamcrest, HamKrest

How Kensa Differs from Cucumber and JBehave

Cucumber and JBehave use Gherkin — a separate plain-text language where scenarios are written in .feature files and then mapped to test code via step definitions. This keeps non-technical stakeholders involved but introduces a permanent gap between the spec and the implementation: step glue code drifts, Gherkin files go stale, and reports reflect the spec rather than what the code actually does.

Kensa takes a different approach: tests are written entirely in Kotlin or Java, using a fluent Given-When-Then DSL. There are no feature files and no step definitions. The HTML report is generated by parsing the test source directly at runtime, so it is always an accurate reflection of the test as written.

Because everything is plain code, your IDE's refactoring tools work across the full test suite without any extra steps. Rename a method or parameter and the change propagates everywhere — including what appears in the HTML report. With Cucumber or JBehave, renaming a step definition leaves the .feature or .story files out of sync, breaking the mapping silently until the next test run.

	Kensa	Cucumber (JVM)	JBehave
Test language	Kotlin / Java	Gherkin + Java/Kotlin	Gherkin + Java
Step definitions	Not required	Required	Required
Reports generated from	Live test source code	Gherkin feature files	Gherkin story files
IDE refactoring support	Full — pure code, no external files	Partial — step definitions refactor but feature files don't	Partial — step definitions refactor but story files don't
Sequence diagrams	Built-in	Not built-in	Not built-in
Framework support	JUnit 5/6, Kotest, TestNG	JUnit 5, TestNG	JUnit, TestNG, Spring Test

Kensa is the right fit if your team writes and owns the tests in code and wants reports that stay honest to what is actually being tested.

It is not trying to replace your unit-testing tools. Kotest's BehaviorSpec and Spek give you Given-When-Then structure for unit and integration tests, and they are good at it — reach for them there. Kensa earns its place when someone who cannot read the code needs to understand what the system does.

Getting Started

Add the dependency for your test framework:

// build.gradle.kts
dependencies {
    // The BOM lines up every Kensa artifact on one version — always use it.
    testImplementation(platform("dev.kensa:kensa-bom:<version>"))

    // Pick your test framework
    testImplementation("dev.kensa:kensa-framework-junit5")   // or -junit6, -kotest, -testng

    // Pick one or more assertions bridges
    testImplementation("dev.kensa:kensa-assertions-assertj") // or -kotest, -hamcrest, -hamkrest
}

kensa-core arrives transitively — you don't declare it. Find the latest version on the releases page.

See the Kotlin quickstart or Java quickstart for a full setup walkthrough.

Tooling

CLI — serve reports locally

Copy the wrapper script from cli/wrappers/ into your project root (kensa for macOS/Linux, kensa.bat for Windows) and commit it. The wrapper auto-downloads the binary for your OS and architecture from GitHub releases and keeps it up to date; set KENSA_VERSION to pin a release instead.

kensa --dir build/kensa-output

This starts a local HTTP server and opens your HTML reports in the browser. You can also define named folders in a .kensa-properties file — see the CLI docs for details.

IntelliJ Plugin — open reports from your IDE

Install the Kensa plugin from the JetBrains Marketplace to open any Kensa report directly from IntelliJ IDEA — no hunting through the filesystem.

• Gutter icons on test functions
• Links in the test console output
• Test toolbar actions

AI Agent Skills — teach your AI assistant Kensa

The kensa-dev/agent-skills repository ships a skill that teaches AI coding agents to write and review idiomatic Kensa tests. Works with Claude Code, OpenCode, and any agent that supports SKILL.md.

For Claude Code:

/plugin marketplace add kensa-dev/agent-skills
/plugin install kensa

See the AI Agent Skills docs for OpenCode, JetBrains AI Assistant, GitHub Copilot, and Cursor instructions.

Community

Questions, ideas, and feedback welcome in GitHub Discussions.