add-cucumber-tests

BDD Test Generation with Tzatziki

Generate valid Cucumber .feature files from a user's functional specification, using Tzatziki's step definition library as the source of truth for legal step patterns.

Principles

These explain the reasoning behind the workflow — understanding them helps you handle edge cases the workflow doesn't explicitly cover.

1. Steps come from code, not imagination. Tzatziki provides hundreds of pre-built @Given / @When / @Then patterns in its *Steps.java files. Inventing step text that doesn't match a real definition produces UndefinedStepException at runtime. Per-module reference files in references/steps-*.md contain every legal step pattern — read the relevant ones before writing any scenario.

   ⚠️ Never paraphrase or improvise step keywords. Many step patterns use regex constants like COMPARING_WITH that expand to a small fixed set of keywords (e.g., "" empty, " exactly", " at least", " only"). Do not substitute natural-language synonyms such as "containing", "including", "matching", or any other word that "sounds right" — if the word does not appear in the @Given/@When/@Then annotation regex, the step will be undefined at runtime. When in doubt, re-read the Java source in references/steps-*.md rather than guessing.

2. Verify the environment before writing tests. Run at least one existing Cucumber test in the target module before creating new feature files. This catches missing dependencies, broken bootstrap, or misconfigured runners early — before you've invested effort in writing scenarios that can't execute. If no test exists yet, create the minimal bootstrap first and confirm it discovers at least one scenario.

3. YAML by default for structured data. Tzatziki scenarios are most readable when request bodies, database fixtures, Kafka payloads, and expected results use """yml doc strings. Fall back to Gherkin tables for naturally tabular data, or raw JSON only when the contract requires it.