Cucumber earns its place on one kind of test: an acceptance test whose output someone outside the development team reads. A tester, an analyst, a product owner. That reader is the only reason to put Given-When-Then on a test at all. Unit tests are code, and developers can read code.

I wrote Kensa for that reader, and it works the same in Kotlin and Java. This post takes a Cucumber scenario, moves it to Kensa, and maps the rest of Cucumber's concepts across, so you can see what a move involves before you start one. If you want the argument for dropping feature files first, that's in BDD Without Gherkin.

I've been writing acceptance tests in Given-When-Then since 2009 and I've never written a feature file by choice. So when someone asks whether you can do BDD without Gherkin, my answer is that I've never done it any other way.

Cucumber has been the default for long enough that the two have merged in people's heads. They shouldn't have. BDD is a way of specifying behaviour. Gherkin is a file format one family of tools uses to do it.

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 sentence.

That's the idea I've been chasing ever since, and it's why I wrote Kensa. So this is a biased guide. It's also a short one.

If you've ever set up Cucumber on a JVM project, you know the overhead: feature files, step definitions, the glue code that ties them together, and the constant friction of keeping all three in sync as your codebase evolves. The promise — shared, readable specifications — rarely survives contact with a real team.

Kensa takes a different approach. Write your Given-When-Then tests directly in Kotlin or Java. No Gherkin. No step definitions. No separate files to maintain.