Video series · Episode 8 · 10–12 min

Test once, run everywhere: BDD in Chenile

The same Gherkin feature file as both a fast MockMvc unit test and a full REST Assured integration test. Write the behaviour once; choose where it runs.

← All episodes

Episode goal: show, live, that a single .feature file runs as an in-process MockMvc test and as a REST Assured integration test — reinforcing the series’ theme (write once, place by configuration) on the testing axis.

Cold open
On camera: “We’ve kept business logic pure and governance consistent. Now — how do we test all of it without writing everything twice? Same trick as always: write the behaviour once, choose where it runs.”
The spec
On screen: open service.feature. Voiceover: “This is Gherkin. It says what the service does, never how the request is sent. That one property is why we can run it at two levels.”
Lower third
“One Gherkin vocabulary. Two step libraries.” Show the recurring diagram: one feature file branching to a MockMvc box and a REST Assured box.
Demo — unit level
Open CukesRestTest, CukesSteps, SpringTestConfig. Point at the glue: org/chenile/cucumber/rest from cucumber-utils. Run it. “No server, no network — Spring MockMvc stands the service up in-process and drives it from outside.”
The key insight
Voiceover: “Notice the request goes through the real Chenile controller and pipeline. So this isn’t a narrow method test — it exercises the service and its interceptors. We’re testing the security, tenancy and i18n policies too. Governance is under test.”
Demo — integration level
Switch to the integration runner whose glue points at it-cucumber-utils from chenile-bdd. Deploy the service (container or staging). Run the same feature file. “Same scenarios. But now I POST a REST request… is REST Assured hitting a real URL over HTTP.”
Diff on screen
Side-by-side the two RestCukesSteps: identical @When/@Then text, different engine — MockMvc vs RestAssured.given(). “Swap the glue, not the spec.”
Payoff
Voiceover: “Fast in-process tests on every build; full REST Assured tests before release — from one specification. Your Gherkin doubles as living documentation. And it-cucumber-sec-utils does the same for secured endpoints.”
Callback
“Same philosophy as the whole series: write it once, decide placement by configuration. Policies at the gateway or last mile; a spec as a unit or integration test.”
Recap card
“One .feature, two step libraries: MockMvc (cucumber-utils) for unit tests, REST Assured (chenile-bdd) for integration. Swap the glue, not the spec.”

Companion reading: Test once, run everywhere: BDD across unit and integration