Spec-Driven Development: How to Turn Specs into Test Cases

Write the spec once, then build the code and the tests from it. A practical guide with a worked example from requirement to test case.

For developers building with AI coding agents, and the QA engineers and product owners who work beside them.

What Is Spec-Driven Development?

Spec-driven development is an approach where a written specification of a feature (its requirements, acceptance criteria, design and tasks) is agreed before any code is written, and becomes the single source of truth that both the implementation and the tests are built from.

The spec is a living document in the repository. Developers, and increasingly AI coding agents, implement against it; QA derives test cases from it; reviewers check the result against it.

Spec first

Intent is written down and reviewed before implementation starts.

One source of truth

Code, tests and reviews all point back to the same numbered requirements.

Verifiable result

Every requirement has tests that prove it, so "done" is measurable.

Why Spec-Driven Development Grew with AI Coding Agents

AI coding agents produce their best work from precise context. A clear spec gives the agent the rules, limits and scope it needs, and gives the team a document to review before hundreds of lines of code appear. Tools such as GitHub Spec Kit and Kiro build the workflow in: spec, then a technical plan, then a task list, then implementation.

The same spec is just as useful to testers. When the code is generated quickly, independent tests written from the spec are how the team confirms the code does what was intended.

TDD vs BDD vs Spec-Driven Development

Test-driven development (TDD) is a coding practice where the developer writes a failing unit test first, writes just enough code to make it pass, then refactors: red, green, refactor. Behaviour-driven development (BDD) describes behaviour as Given / When / Then examples agreed by the team. Spec-driven development works one level up, at the whole feature:

	TDD	BDD	Spec-driven
Starts from	A failing unit test	A behaviour example in Given / When / Then	A written specification of the feature
Written by	The developer	Product, development and QA together	Product and engineering, often drafted with an AI agent and reviewed by people
Unit of work	One function or class	One user behaviour	One feature or change, split into tasks
Tests produced	Unit tests	Executable scenarios, often automated with Cucumber-style tools	Test cases derived from each requirement, manual or automated
Best for	Clean, well-designed code	Shared understanding of behaviour	Keeping AI-written code aligned with intent

The three combine well: the spec defines the feature, BDD-style examples can live inside it, and TDD guides the code that implements each task.

What Makes a Spec Testable

A testable spec lets two people independently write the same test for each requirement. These five qualities get you there:

Quality	Hard to test	Testable
Observable outcome	Reset should be easy	The user sees "Check your email" within 2 seconds
Explicit limits	Links expire after a while	Links expire 30 minutes after they are sent
Error behaviour	Handle bad input	A password under 12 characters shows "Use at least 12 characters"
Who it applies to	Users can reset passwords	Users with email login; SSO users are out of scope
A unique ID	A paragraph of prose	REQ-3: one numbered, independently checkable statement

A simple sentence pattern helps: When <trigger>, the system shall <response>, known as EARS (Easy Approach to Requirements Syntax). For formats at the story level, see Acceptance Criteria: The Foundation of Effective QA.

From Spec to Test Cases: A Worked Example

Here is a short spec for a password reset feature, written the way an AI agent and a tester can both use it:

Spec: Password reset (v2)

REQ-1 When a registered email is submitted, the system shall send a reset link. REQ-2 When an unregistered email is submitted, the system shall show the same confirmation message. REQ-3 The link shall expire 30 minutes after it is sent and work only once. REQ-4 The new password shall be 12 to 64 characters. Out of scope: users who sign in with SSO.

Each requirement turns into a small group of cases: the positive path, the negative path, and the values at each limit.

ID	Requirement	Test cases
REQ-1	When a registered email is submitted, the system shall send a reset link	Registered email receives the link; confirmation message is shown
REQ-2	When an unregistered email is submitted, the system shall show the same confirmation message	Unregistered email shows the identical message; no email is sent
REQ-3	The link shall expire 30 minutes after it is sent and work only once	Link used at 29 and at 30 minutes works; at 31 minutes it is rejected; a second use is rejected
REQ-4	The new password shall be 12 to 64 characters	11 characters rejected; 12 and 64 accepted; 65 rejected

Putting the requirement ID in each test case title gives you traceability for free: when REQ-3 changes, you know exactly which cases to update. The limit values come from boundary value analysis, explained in Test Case Design Techniques.

Keeping Spec, Code and Tests in Sync

Version the spec with the code, so every build has a matching spec version.
Write tests from the spec, independently of the code, so they confirm intent rather than mirror the implementation.
When a requirement changes, update the spec first, then the affected test cases, then the code.
Re-run the cases for changed requirements on every build, and keep the results with the build number.

Spec-Driven Testing in Evaficy Smart Test

Evaficy Smart Test generates test cases from the text you give it, so a well-written spec maps directly onto its inputs.

Each generation produces up to 10 test cases, usually around 7, for one test type. Run one pass per type (for example Functional, then Boundary Edge Case) to build the full set.

Map each part of the spec to a field

Custom field labels are free text, so each part of the spec can go into its own field. Two labels are strict: Requirement and Acceptance Criteria. Every generated case must respect them, and the set must cover them. Any other field is applied together with the test type and affected page, which makes it a good place for roles, exclusions and platforms.

Spec section	Custom field	How generation uses it
Functional rules (REQ-1 to REQ-4)	Requirement	Strict: every case must respect it and the set must cover it
Acceptance criteria block	Acceptance Criteria	Strict, same as Requirement
Who it applies to	User role: Email-login user	Applied together with the test type and page
Exclusions	Out of scope: SSO users	Applied together with the test type and page
Target platform	Browser: Safari 17	Applied together with the test type and page
Spec version	Spec version: v2	Saved with the scenario for traceability

The fields are saved with the scenario, so reopening it later shows exactly which spec version and constraints the cases came from. More input tips are in Writing Effective Inputs for AI Generation.

Review before execution

On Advanced and Enterprise, the validation workflow sends a scenario for review, and an Owner, Product Owner or Tech Lead approves or rejects it. This is the moment to check the cases against the spec. See The Expert Validation Workflow.

One pass per test type

Use Functional for REQ-1 and REQ-2, Boundary Edge Case for the limits in REQ-3 and REQ-4, and Acceptance for the end-to-end sign-off view.

Generate from your coding agent with the Evaficy MCP

If the spec lives in your repository, the Evaficy MCP lets Claude Code, Cline, Cursor or another MCP-capable client generate test cases without leaving the editor. The generate_test_cases tool takes a test type, the requirement, an optional affected page and extra label and value criteria. It returns a preview, or saves a new scenario when you name a project and scenario. get_test_case lets the agent read the saved steps and validation status back.

Example prompt

Read specs/password-reset.md. Generate Boundary Edge Case test cases for REQ-3 and REQ-4, with "Out of scope: SSO users" as an extra criterion. Show me a preview first, then save them as "Password reset v2: limits" in the Web App project.

Good to know

Generating through the MCP uses the same AI quota as the app: 5 generations in total on Basic, 200 per month on Advanced and 500 per month on Enterprise. A preview counts as a generation, so refine the requirement text before you run it.

Common Questions

Is spec-driven development the same as BDD?

They are related. BDD expresses behaviour as Given / When / Then examples agreed by the team. Spec-driven development writes a fuller specification of the feature first, which can include BDD-style examples, and uses it as the source for both the code and the tests.

Is test-driven development still worth it with AI coding agents?

Yes. TDD works at the level of code units and gives fast feedback on design and regressions. Spec-driven development works at the level of the feature. Many teams use the spec to define the feature and TDD inside the implementation, including asking the agent to write the failing test first.

Who should write the spec?

The product owner or developer who owns the feature usually drafts it, often with help from an AI agent, and QA reviews it for testability before implementation starts. The review is where missing limits and error cases get added.

Do I still need test cases if the spec is detailed?

Yes. The spec says what should happen; test cases record how to check it, with steps, data and expected results, and they keep a record of each run. A detailed spec makes the test cases faster to write and easier to trace.

How detailed should a spec be?

Detailed enough that two people would write the same test for each requirement. Numbered requirements with explicit limits, error behaviour and scope usually reach that point in one or two pages per feature.

Does generating test cases from the Evaficy MCP use my AI quota?

Yes. Each generate_test_cases call counts toward the same AI generation quota as generating in the app: 5 generations in total on Basic, 200 per month on Advanced and 500 per month on Enterprise. Previewing without saving still counts as a generation.

Key Takeaways

Spec-driven development agrees a written spec first and builds both the code and the tests from it.
It suits AI coding agents, which produce better code from precise, reviewed context.
TDD works on code units, BDD on behaviour examples, spec-driven development on the whole feature; they combine well.
A testable spec has observable outcomes, explicit limits, error behaviour, scope and numbered requirement IDs.
Turn each requirement into positive, negative and boundary cases, and put the requirement ID in the case title.
In Evaficy Smart Test, put rules in Requirement or Acceptance Criteria and constraints in other custom fields.

Turn your next spec into test cases

Create a free account, paste one requirement into the Requirement field and review the cases it produces. The Basic plan includes 5 AI generations.

Create your free account