Build1 publisher3 min readPublished
Copying Given/When/Then out of Jira leaves four texts that have to agree
Gherkin's one real feature is a non-developer authoring scenarios in plain text. A post on dev.to argues that on real teams the criteria are written in Jira and a developer retypes them, leaving four texts to keep in agreement.
The Engineer · Build desk
What happened
- On every team the dev.to post's author has seen, the Given/When/Then goes into the Jira ticket first, and a developer then types the same words into a feature file and writes step definitions to bind them.
- That leaves three texts that must stay in agreement, the feature file, the step definitions and the code, and the post says the IDE can refactor only two of them.
- Binding is by regular expression, so renaming a method does not move the .feature file, and rewording a step changes the match silently.
- The report colours the Gherkin green or red, and the request that went in, the messages between services and the response that came back stay out of the feature file.
- The post keeps one carve-out: a team whose tester or analyst opens the repository, writes .feature files and runs them is getting exactly what the format was built for.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Two of the four copies sit outside every rename and compile check, so agreement between the ticket and the feature file depends on a person noticing a wording change.
- decision The choice to keep or drop Cucumber turns on a single local fact, whether anyone outside the development team authors the files, and that is answerable from a repository's own history.
- cost Leaving Gherkin carries its own cost: JGiven charges a stage class per scenario and cannot put a runtime value into a sentence built from a method name.
- capability A report generated from the run can carry the messages between services, their payloads and a sequence diagram drawn from that traffic; a plain-text feature file has nowhere to put any of it.
Cucumber arrived around 2008, when IDE refactoring support was patchy and parsing test source at runtime was not practical, so a plain-text file bound to code by matchers answered the constraints of its day [11]. "I don't think it was ever a great answer. It was the available one," the post's author wrote [12]. He argues the constraints are gone and the costs stayed [13]. The capability that was missing in 2008 is the one his replacement needs. Kensa parses the test method at runtime and renders the given, the when and the then as sentences carrying this run's values [16].
Count the texts on a team that keeps its acceptance criteria in Jira. The three the post lists, plus the ticket the words were copied from, is four [21]. Two of them are under the IDE's rename [22]. The other two, the feature file and the ticket, are prose, and no build step reads them [22].
Step definitions are the part that grows. They are where the logic actually lives, and the post counts them as neither specification nor test [9]. "Gherkin promised living documentation and delivered a feature file with colours," he wrote [20].
In the Kensa example, `@Issue("PROJ-42")` links the generated report back to the ticket, so the analyst who wrote the Given/When/Then in Jira can open the report and see what the system did [17].
This rests on one practitioner's experience across teams, not a measured population. The post says its author has been writing Given-When-Then acceptance tests since 2009 [1], and of testers and analysts writing feature files themselves, "I've never seen it" [4]. He is explicit that a team where the tester or analyst does open the repository, writes .feature files and runs them should keep Cucumber [3]. In a given repo, the commit log on the .feature files says who writes them.
JGiven takes a different route. Sentences are derived from method names, so `given().a_paid_order()` renders as "Given a paid order", and refactoring keeps the two in sync. The price is a stage class for every scenario, and a sentence that cannot carry a runtime value [15]. Where only developers read the output, the post's advice is to add nothing: Kotest's BehaviorSpec or JUnit with good method names gives Given-When-Then in code with refactoring intact. The author uses that himself [14].
Kensa is open source, and the test in the post's example is ordinary Kotlin [19][16]. What survives either choice is the practice the format was carrying: one concrete example per test with a given, a when and a then, in the words from the ticket, failing in CI when the behaviour changes [23].
What to watch
- Any team where a tester or analyst authors and runs .feature files unaided; that case keeps the format's original justification intact.
- Whether runtime parsing of the test method has equivalents outside Kotlin, since the post's worked example is Kotlin.
- Whether JGiven's stage class per scenario turns out cheaper in maintenance than a runtime parser.