Generic AI tools produce generic test cases. Here is how to teach AI your team's terminology, structure, and voice so generated tests match the way you already work.
Originally published at dokim.krinosystems.com
Most AI test generators promise speed. Paste a story. Get tests. Stop writing everything by hand.
In practice, most teams hit the same wall. The generated tests do not sound like their own tests. The terminology is slightly off. The structure is different. The scenarios feel generic. People recognize the patterns from blog posts and marketing demos, not from their own codebase.
So the team keeps its existing style for "real" tests and treats the AI output as a suggestion rather than something they can drop into the suite.
The problem is not that the AI cannot write tests. The problem is that it has never seen how your team writes tests. It is guessing a reasonable default, not following a local convention.
This matters because readable Gherkin depends on familiarity. Scenarios work best when they use the language the team already uses in conversation, tickets, and code reviews. If AI-generated scenarios feel like they came from a different team, reviewers have to mentally translate before they can evaluate.
The fix is not better prompts. The fix is better examples.
Why AI Output Sounds Generic
Large language models generate text by predicting what comes next based on patterns in their training data. When given a user story and asked to produce Gherkin, the model draws on thousands of examples it has seen before.
The result is a kind of averaged output. The scenarios reflect general BDD conventions rather than any specific team's conventions. They are correct in the way a textbook example is correct: syntactically valid, conceptually sound, and completely impersonal.
This is not a flaw in the model. It is a consequence of how generation works. Without context about a specific team's style, the model has no way to know that this team says "workspace owner" instead of "admin user," or that this team always includes explicit negative assertions, or that this team prefers short scenario names over longer descriptive ones.
The model needs examples to learn from. Not hundreds. Just a few good ones.
The Few-Shot Principle
Few-shot learning is a technique where a model is given a small number of examples before being asked to generate new output. The examples act as a style guide, showing the model what "good" looks like for this specific context.
For test generation, this means providing 2-3 complete examples of user stories paired with the Gherkin scenarios the team considers well-written. The model uses these examples to calibrate its output: matching terminology, mirroring structure, adopting the same level of detail.
The principle is simple: show, do not tell.
Telling the model "use domain-specific language" is vague. Showing the model examples where "suspended account" appears instead of "inactive user status" is concrete. The model learns the pattern from the examples rather than trying to interpret an instruction.
This is why reference examples work better than elaborate prompt engineering. A few real examples communicate more about a team's style than paragraphs of description ever could.
What Makes a Good Reference Example
A reference example is a paired input and output: a user story on one side, the Gherkin scenarios the team would write on the other.
Good reference examples share several characteristics.
They are real. The best examples come from scenarios the team has already written, reviewed, and approved. These reflect actual decisions about terminology, structure, and coverage. Invented examples tend to drift toward generic patterns.
They are representative. The examples should reflect the team's typical style, not edge cases or exceptions. If the team usually writes 4-6 scenarios per story, the examples should show that range. If the team usually includes explicit "should not" assertions, the examples should include them.
They are complete. Each example should show the full story and the full set of scenarios. Partial examples teach partial patterns. The model needs to see how the team handles the whole decomposition, not just individual steps.
They are few. Two to three examples is usually enough. More examples add diminishing returns and increase the risk of conflicting patterns. If two examples show different conventions, the model has to guess which one to follow.
The goal is not to cover every possible case. The goal is to establish a clear baseline that the model can generalize from.
What to Include
Reference examples should demonstrate the stylistic choices that matter most to the team.
Terminology. If the team uses specific domain terms, the examples should use them consistently. "Workspace," "billing cycle," "trial period," "payout" are all terms that might differ from generic alternatives.
Step granularity. Some teams prefer fine-grained steps that specify every precondition. Others prefer coarser steps that bundle related setup. The examples should reflect the team's preferred level of detail.
Assertion patterns. Does the team always include explicit negative assertions ("And no email should be sent")? Does the team prefer "should" or "must" or simple present tense? The examples establish the pattern.
Scenario naming. Some teams use short names ("Valid coupon applies discount"). Others use longer descriptive names ("User with valid percentage coupon sees reduced cart total"). The examples show the convention.
Coverage depth. Do the examples show quick happy-path coverage or exhaustive edge-case coverage? The model will match the depth it sees in the examples.
A complete reference example looks like this:
# Story input
Story: Apply percentage coupon
As a registered user
I want to apply a coupon during checkout
So that I can receive a discount on my cart total
Acceptance Criteria:
- Valid coupon reduces cart total by the percentage value
- Expired coupon shows an error and does not change the total
- Coupon cannot be applied twice to the same cart
# Team's ideal output
Scenario: Valid coupon reduces cart total by percentage
Given I have items in my cart totaling $50
And I have a valid coupon "SAVE20" for 20% off
When I apply the coupon
Then my cart total should be $40
And I should see "20% off applied"
Scenario: Expired coupon shows error and preserves cart
Given I have items in my cart totaling $50
And I have an expired coupon "OLD20"
When I apply the coupon
Then I should see "This coupon has expired"
And my cart total should remain $50
That pair tells the model how to name scenarios, how to express Given/When/Then, how specific to be about outcomes, and how to phrase messages. Add one more example from a different feature to show the pattern is consistent across the product.
What Not to Include
Reference examples should not try to do the model's job.
Do not include edge cases to force edge-case generation. The examples teach style, not coverage. If the team wants exhaustive coverage, that is a coverage-level setting, not something encoded in examples. Stuffing edge cases into reference examples confuses style guidance with coverage guidance.
Do not include negative paths just to force negative-path generation. If your team routinely writes negative assertions, include one that shows the pattern. The goal is representative style, not coverage manipulation.
Do not include conflicting patterns. If one example uses "Given I am logged in" and another uses "Given the user is authenticated," the model receives mixed signals. Pick one convention and use it consistently across all examples.
Do not include complex or unusual stories. The examples should be typical, not exceptional. A complex multi-actor workflow might be a valid test case, but it is a poor reference example because it introduces patterns the model will try to replicate in simpler contexts.
The examples are a style guide, not a test plan. Keep them clean and consistent.
Before and After
The difference is visible in the output.
Without reference examples:
Scenario: User applies discount code
Given the user is on the checkout page
And the user has items in cart
When the user enters discount code "SAVE20"
And the user clicks Apply
Then the discount should be applied
And the total should be updated
This is generic. "The user" instead of "I." "Clicks Apply" instead of a domain action. "Should be applied" without specifying what that means.
With reference examples showing the team's style:
Scenario: Valid coupon reduces cart total by percentage
Given I have items in my cart totaling $50
And I have a valid coupon "SAVE20" for 20% off
When I apply the coupon
Then my cart total should be $40
And I should see "20% off applied"
This matches the team's conventions: first person, domain-level steps, concrete values, explicit message assertion. The model learned the pattern from the examples.
The content is similar. The style is different. That difference determines whether reviewers read the scenario or skip it.
Maintaining Examples Over Time
Team conventions evolve. New domain terms emerge. Old patterns get deprecated. The reference examples should evolve with them.
Review the reference examples whenever the team updates its testing standards. If the team decides to start including performance thresholds in scenarios, update an example to show the new pattern. If the team deprecates a term, remove it from the examples.
The examples are a living artifact, not a one-time setup. Treating them as static defeats the purpose. The model will keep generating in the old style until the examples reflect the new one.
For teams that version-control their test assets, the reference examples can live alongside the feature files. Changes to conventions get tracked the same way changes to tests get tracked.
Checklist
When setting up or refining AI-generated tests:
- Pick 2-3 representative stories that reflect normal work, not edge cases.
- Write or select ideal scenarios for those stories that show your naming, structure, and assertion style.
- Configure these pairs as reference examples in your generation tool.
- Generate tests for a new story and compare the output against your examples.
- Adjust examples if the output is still off.
- Review examples periodically to keep them aligned with current conventions.
Tools can generate scenarios quickly. Fit with your team's style is still a human judgment.
Summary
AI-generated scenarios match a team's style when the AI has examples to learn from.
A few well-chosen reference examples, 2-3 complete story-to-scenario pairs, teach the model more about terminology, structure, and conventions than any prompt instruction could. The examples act as a style guide that shapes every subsequent generation.
The discipline is not writing more examples. The discipline is choosing examples that represent how the team actually writes.
Show, do not tell. The model will follow.
