AI 時代實用指南：TDD、BDD、ADD、SDD、EDD 應如何選用？

short glimpse

TL;DR: Five acronyms, one question: how do you know the software does what you wanted?

TDD verifies your code.
BDD verifies your behaviour.
ADD / ATDD verifies your agreement.
SDD verifies the work of your AI coding agent.
EDD verifies the AI output you ship.
You don't pick one. You stack them — and this article tells you where each one goes.

Read further for deepdive.

The Question Behind All Five

Five terms, five philosophies. And if you've been drowning in newsletters lately,

you've probably felt the same confusion: is this a testing strategy? A process? A mindset? Are they fighting each other?

My take on this is: none of these are really "testing strategies." They're all answers to the same question, asked at different moments in software history:

How do you know the software does what you want?

we are in the phase - AI writing the code. Writing code got cheap, fast, and almost free. Verifying code got more expensive, not less. These five practices, in different ways, are all verification tools.

Let's meet the family, one by one.

The Family Tree (1990s → 2026)

 1990s            2003–06             2000s             2024–26             2025
    │                │                  │                  │                 │
   TDD ───────────► BDD                ADD                EDD              SDD
 Kent Beck        Dan North         agile testing    Hamel Husain   GitHub Spec Kit
 (Extreme         (grew out of      (usually written & Shreya Shankar,  + OpenSpec
  Programming)     TDD)              as ATDD)        Airbnb practice
    │                │                  │                  │                 │
    └────────────────┴──────────────────┘                   │                 │
           "know what to build"                            │                 │
      (tests, behaviours, the agreement)                   │                 │
                                                           └────────┬────────┘
                                                                    │
                                                "verify what an AI just built
                                                  (and what it shipped)"

The split is not a coincidence. The first three exist to prevent building the wrong thing. The last two exist because a new builder entered the room — one that's fast, tireless, and has zero stake in your product.

TDD: The Loop That Changed Everything

Test-Driven Development was formalized by Kent Beck in the late 1990s, as part of Extreme Programming. The standard summary of the loop:

              ┌───────────┐
         ┌───►│   RED     │  write the next failing test
         │    └─────┬─────┘
         │          ▼
         │    ┌───────────┐
         │    │   GREEN   │  write just enough code to pass
         │    └─────┬─────┘
         │          ▼
         │    ┌───────────┐
         │    │ REFACTOR  │  clean it up, tests stay green
         │    └─────┬─────┘
         │          │
         └──────────┘   (repeat, forever)

Why it works

Two benefits, per Martin Fowler.

1. First, your code is self-testing — you can only write production code in response to making a test pass.

2. Second, and the underrated one: thinking about the test forces you to think about the interface first. You design how the thing is used before deciding how it's built.

The most common way people screw up TDD is skipping step three. No refactoring means a messy aggregation of code fragments — the tests stay green, the code doesn't.

BDD: Tests That Read Like English

Behaviour-Driven Development was coined by Dan North. North was teaching TDD and kept hitting the same wall: beginners asking where do I start, what should I test, what do I call this, why did it fail?

His answer was a reframe. Stop saying test. Start saying behaviour.

BDD has three parts:

1. Discovery — structured conversations around real-world examples of how the system should behave.
2. Formulation — writing those examples down in a human-readable, executable format (usually Gherkin).
3. Automation — wiring the examples to the running system as tests.

Feature: User login

  Scenario: Successful login
    Given a registered user exists
    When the user submits valid credentials
    Then they are redirected to the dashboard

The mechanics worth knowing:

• Test names are sentences, not testFailsForDupes.
• The "should" template: every test fits the class **should* do something*. The word "should" quietly invites you to challenge the premise — should it, really? That's how stale assumptions get caught.
• The story shape: As a [X], I want [Y], so that [Z]. The "so that" forces you to state the value — and half of all feature requests die there, honestly and quickly.
• A ubiquitous language (borrowed from Domain-Driven Design): the same words appear in the requirement, the test, and the code. When everyone shares a vocabulary, miscommunication — one of the most expensive bug sources in software — drops.

BDD is for deterministic systems. The output of a login form is either correct or it isn't. assert redirect_url == "/dashboard" is a valid test. Tools: Cucumber, SpecFlow, Behave, pytest-bdd, Jest + Testing Library.

ADD: The Contract You Sign Before the Machine Starts

Acceptance-Driven Development / ATDD (Acceptance Test-Driven Development).

The idea is simple: before anyone writes a line of code, the team — developers, testers, and the business person — writes the acceptance criteria for the story. In natural language. End to end.

                     ─────────
                    ╱   ADD   ╲  acceptance: "what does done mean?"
                   ╱    the    ╲ team signs off BEFORE any code
                  ╱  contract   ╲
                 ╱───────────────╲
                ╱       BDD       ╲  behaviour: "what should it do?"
               ╱    Given/When/    ╲ scenarios in plain English
              ╱─────────────────────╲
             ╱          TDD          ╲  unit: "does this function work?"
            ╱       red-green-        ╲ smallest, fastest, cheapest
           ╱───────────────────────────╲

Read that pyramid from the bottom up: TDD checks the parts, BDD checks the behaviour, ADD checks the agreement. Each level is slower, coarser, and closer to the business.

A story in full ADD dress:

Story: As a user, I want to reset my password, so that a compromised account is less dangerous.

Acceptance criteria:

• A reset link expires after 30 minutes.
• A reset link can only be used once.
• A user with 2FA must re-verify their identity after a reset.
• The account is logged out everywhere after a reset.

That's the whole practice. The criteria are written before implementation, reviewed by the people whose jobs depend on the feature, and become the tests the finished feature must pass. Each of the three roles gets something:

• The developer knows the exact shape of "done" before starting — and the shape rarely changes mid-build.
• The tester designs the verification while it's still cheap to change, not after the code exists.
• The business person signs off on behaviour in a language they actually read.

SDD: The Spec Is the Source of Truth

Spec-Driven Development is the newest heavyweight.

• GitHub Spec Kit (github/spec-kit) — GitHub's open-source toolkit (140k+ stars as of Oct 2026) for spec-driven work with AI coding agents; bug-fix and idea-assessment flows ride along, but SDD is the flagship.
• OpenSpec (openspec.dev, by Fission-AI) — a lighter-weight community framework where specs live in your repo as first-class artifacts (73k+ stars).
• AWS Kiro — an IDE with the spec-driven flow (specs, requirements, project steering docs) baked into the editor; where many teams first meet SDD.

The fundamental problem SDD solves: if you let an AI agent write both the component and the tests for it, the agent will unconsciously write **tests that pass — not tests that verify.

** SDD ** breaks that cycle by locking the spec before any code exists. The spec is written by a human. The code is written by the agent.

The spec is the non-negotiable contract between them.

OpenSpec's mental model is the contract and the contractor: a contractor who shows up with no blueprint builds whatever they think you meant. OpenSpec is the contract. The agent is the contractor.

The Spec Kit flow

 /speckit-constitution      once per project: principles (quality, tests, style)
        │
        ▼
 /speckit-specify ──► /speckit-plan ──► /speckit-tasks
    what & why         stack &            the spec, broken
                       constraints        into an ordered task list
                                              │
                                              ▼
                       ┌────────────────────────────────────┐
                       │ /speckit-implement                 │
                       │          │                         │
                       │          ▼                         │
                       │ /speckit-converge                  │
                       │  does the code match the spec?     │
                       │       │ no        │ yes            │
                       │       └───────────► "Converged"    │
                       │          (fix & re-implement)      │
                       └────────────────────────────────────┘

Two details deserve emphasis. The constitution is the spec for specs — your project's non-negotiables, written once.

converge is a verb the pre-AI world didn't need: TDD asks "do the tests pass?"; SDD asks something stricter — does what was built match what was specified, end to end? The spec is the source of truth; the code is the claimant.

The OpenSpec flow

 /opsx:explore                     optional: a no-stakes thinking partner —
                                   reads the codebase, shapes the plan
        │
        ▼
 /opsx:propose <feature>           agent writes the spec. No code yet.
        │
        ▼
 /opsx:apply <feature>             agent writes code strictly following the spec
        │
        ▼
 /opsx:archive <feature>           the change is folded into the main spec,
                                   permanently

Lighter than Spec Kit:
each change is a folder of plain Markdown —
proposal.md,
specs/ (requirements and scenarios),
design.md,
tasks.md — reviewed by a human before any code is written.

Command spellings vary by tool (/opsx-propose, $openspec-propose); openspec init prints the right form for yours.

Why it works (and why it's not "just a good prompt")

Agents are bad at holding thirty requirements in their head across a long session. They're good at following a written document step by step. A spec is a leash with a purpose: it keeps intent outside the model — in a file that survives session restarts, model swaps, context windows, and team changes.

Tell an agent a feature in chat, and the intent dies with the conversation. Write it in a spec, and it outlives everything except your product.

EDD: The TDD of the AI World

Eval-Driven Development that exists because of a specific technical fact: LLM output is probabilistic.

You build a support bot.

You write assert response == "Your order has shipped." and you've written a test that will fail on the first Tuesday of the month, for reasons you cannot predict.

Unit tests assume determinism.
Probabilistic output breaks that assumption, so the whole verification story has to be rebuilt. That rebuild is EDD.

The term was formalized in methodology by Hamel Husain and Shreya Shankar, and got an academic process model in the arXiv paper "Evaluation-Driven Development and Operations of LLM Agents".

The vocabulary in 60 seconds

• An eval is a test that measures whether your AI system is doing what you want. It returns a score or a pass/fail on a set of real or representative examples.
• Product evals vs model benchmarks: benchmarks (MMLU, GPQA, Terminal-Bench) say how a model does on generic tasks. They say almost nothing about your order-cancellation agent. Product evals measure your product against your users' actual needs.
• A trace is the complete record of one session: every message, tool call, and retrieval from first query to final answer. Traces are your raw material — you can't find failures you can't see.

The loop (in the correct order)

 1. RUN the system, collect traces
        │
        ▼
 2. ERROR ANALYSIS
    read 30–100 traces, note every failure,
    group notes into a failure taxonomy
        │
        ▼
 3. BUILD an eval for each failure that matters
    cheap first: code assertions, regex, JSON checks,
    "did it call the right tool?"
    expensive last: LLM-as-judge for judgment calls,
    validated against 100–200 human labels before trusting it
        │
        ▼
 4. FIX → re-run → improved, without regressing?
        │
        └────────► new traces, new failures, repeat

Hamel and Shankar put it in their own FAQ: on serious projects, 60–80% of development time goes to error analysis and evaluation — that is, looking at data, not building dashboards. That ratio is the practice. If your eval workflow is 90% dashboard and 10% looking, you have the wrong workflow.

Two more rules of the road:

• Binary beats Likert. A pass/fail per failure mode beats a fuzzy 1–5 rating.
• Change one variable at a time — prompt, model, or RAG config — then measure. Otherwise you can't tell what actually improved.

The part everyone gets wrong

The naive version of EDD says: "build a golden dataset and a scoring rubric first, then develop."

Here's the correction, from the field's most-cited authority. Hamel Husain's own answer to "Should I practice eval-driven development?" is generally no. His reasoning: unlike traditional software, where failure modes are predictable, LLMs have an infinite surface area for potential failure. You can't anticipate what will break. Writing evals before the system exists means writing evals for failures you imagined — wasted effort, and it blocks you on questions you can't answer until the system exists.

The version that works:

Do error analysis first. Write evals for failures you found, not failures you guessed.

The golden dataset is real and important — but it grows out of error analysis, as a version-controlled set of representative examples and expected quality. It's not something you author on a whiteboard in week one.

One exception: if you have a constraint where you already know exactly what success looks like — "the model must never mention competitor X" — writing that evaluator early is fine. It's a known boundary, not a prediction.

Tools: LangSmith, Braintrust, RAGAS, Arize Phoenix, Weights & Biases Weave.

When to use EDD

• Any LLM-powered feature: chatbots, RAG systems, agents, summarizers, classifiers.
• Any time you change a prompt, model, or retrieval setup and can't tell if it got better or worse. (You can't. Run the evals.)
• Before you trust a "fix" to an AI feature. If it doesn't show up in the evals, it didn't happen.

When EDD is the wrong tool

• Deterministic code with no AI in the loop. That's TDD's job.
• Week one of a new AI feature, when you have no traces yet. (You can bootstrap error analysis on synthetic data — that's standard.)
• When the team's first instinct is to buy an eval platform instead of reading 30 traces. The platform is step four, not step one.

SDD vs EDD: How the Two Split

This is the most common confusion in the field, so here's the clean split:

SDD is for people who are coding and creating applications using coding agents.
EDD is for people who are building AI-powered features as their product.

 SDD's failing signal                  EDD's failing signal
 ┌───────────────────────────┐         ┌───────────────────────────┐
 │ expected button to be     │         │ faithfulness score 0.62   │
 │ visible — FAIL            │         │ < threshold 0.80          │
 └───────────────────────────┘         └───────────────────────────┘
   deterministic · boolean               probabilistic · scored
   "the spec says visible"               "the judge says not faithful"

One sentence: SDD verifies that the agent built what you specified. EDD verifies that what you built is actually good.

When to Use Which: The Decision Guide

Stop treating these as competitors. They stack. Here's the map:

 What are you building / verifying?
        │
        ├─ deterministic code, small change ────────────► TDD
        │
        ├─ business rule, multiple roles in the room ──► BDD
        │
        ├─ "what counts as done?" is ambiguous, ───────► ADD
        │   stakeholders must sign off
        │
        ├─ new feature / app built by an AI agent ─────► SDD
        │
        ├─ AI / LLM output shipped as a product ───────► EDD
        │
        └─ a real product (most projects) ─────────────► all of them,
                                                          layered ↓

The reference table

One Feature, Five Practices

 ┌─────────────────────────────────────────────┐
 │ SDD — the spec                              │  intent: what we decided to build
 ├─────────────────────────────────────────────┤
 │ ADD + BDD — the acceptance criteria         │  agreement: what "done" means
 ├─────────────────────────────────────────────┤
 │ TDD — the unit tests                        │  implementation: the code's truth
 ├─────────────────────────────────────────────┤
 │ EDD — the evals (the AI parts only)         │  quality: the output's truth
 └─────────────────────────────────────────────┘

Case 1: You're building a photo organizer with AI tagging:

 Photo Organizer with AI tagging
        │
        ├─ SDD    spec: "albums grouped by date, tile preview,
        │          AI tags on import, tags editable"
        ├─ ADD    criteria (with the PM): "one album per month;
        │          a tag can be deleted; suggestions appear within
        │          60s for a 100-photo import"
        ├─ BDD    behaviour: timezone grouping, in Given/When/Then —
        │          exactly where "done" gets ambiguous
        ├─ TDD    code: date logic, tag-edit API, preview pagination —
        │          red/green/refactor, agent driving the loop
        └─ EDD    AI tagging: collect traces of real imports, read 30,
                  build the taxonomy ("miscategorizes group photos",
                  "hallucinates tags for non-photo files"), one eval
                  per top failure, fix, re-run

### Case 2: Mobile and On-Device ML

Mobile is where this gets interesting, because a single app might need *multiple* methodologies at once, applied to different parts of the same codebase.

plaintext
A mobile app (Android / iOS / React Native / Flutter)
│
├─ app code: screens, navigation, business logic
│ │
│ ├─ you write it ──────────────► TDD / BDD
│ │ (XCTest, Espresso, JUnit)
│ │
│ └─ an AI agent writes it ─────► SDD
│ (spec first — lifecycle, offline
│ sync, and memory rules live IN the
│ spec, before the agent touches a file)
│
└─ on-device ML feature ──────────────► always EDD
(golden set + precision / recall / latency / RAM)

**Why EDD is harder on mobile.** On-device ML adds a hardware dimension server-side EDD doesn't have. Your golden dataset must cover not just output quality but:

- **RAM footprint** — peak and steady-state across low-end, mid-range, and flagship devices
- **Thermal and battery impact** — CPU / GPU / NPU utilisation under sustained load
- **Inference latency** — time-to-first-token on *real devices*, not simulators (which are too fast and too uniform)

| Platform | ML frameworks | EDD tooling |
|---|---|---|
| **iOS** | Core ML, Create ML, Apple Foundation Models | Xcode Instruments (Neural Engine, Foundation Models), XCTest assertion harnesses |
| **Android** | TensorFlow Lite, MediaPipe, ExecuTorch (NNAPI / GPU delegates) | Android Studio Profiler, custom JUnit eval harnesses against test tensors, Firebase Test Lab |
| **React Native / Flutter** | Core ML / NNAPI via platform channels, ONNX Runtime, ExecuTorch | Firebase Test Lab, BrowserStack real devices, host-side harness driving the native runtime |

The split never changes, whatever the platform: **the app code follows TDD/BDD or SDD depending on who writes it; the AI feature inside the app is always EDD.**

One feature. Five practices. None of them redundant. The spec carried the intent. The acceptance criteria carried the agreement. The behaviours carried the domain rules. The tests carried the code. The evals carried the AI quality. Remove any one and something leaks.

The one-line memory aid

The AI-Era Mistakes we tend to do

The tools are new, so the failures are new too.

1. Trusting the agent's green light.
"The tests passed" — whose tests, run where, by whom? Run the suite yourself. Read the diff. Green means "the tests you have pass." It does not mean "correct." In the agent era, your review of the diff is the review of the agent, not of a colleague.

2. Writing evals for failures you imagined.
Hamel's "generally no" applies. If your eval suite was written before the product existed, it measures your expectations, not the product. Error analysis first, always.

3. Chasing 100% eval pass.
A perfect score is a signal that your evals are soft. The teams getting value live at 70–85% on hard checks and slowly ratchet the bar.

4. Spec rot.
The spec says one thing, the code does another, nobody noticed for three sprints. That's what the converge step exists for. A spec that isn't re-verified is a rumor.

5. Platform before practice.
Buying the fancy eval dashboard in week one instead of spending 30 minutes reading traces. The data is the practice. The platform is furniture.

6. TDD theater.
Tests written after the code that merely mirror the implementation. That's not TDD, that's a screenshot of the code. The test's job is to state intent — the thing that should be true independent of how the code got there.

Your Quick Start

Five steps if you want to do something this week:

1. You ship AI output? Pick 30 real traces from your system. Read them all. Write down every failure. Group them. That failure taxonomy is worth more than any eval platform.
2. Building something new with an agent? Write the spec before the first prompt. Even one page. Future-you will diff against it.
3. Business rules in the mix? Write the acceptance criteria before implementation — one screen, plain language, reviewed by the person who lives with the feature.
4. Every function, human- or agent-written, gets a test. Red first when you can. When the agent says "done," the suite is your definition of done, not its word.
5. Never merge on an agent's say-so. Run it. Read it. Ship it. That last sentence is the entire AI-era engineering methodology, distilled.

The Big Picture

Every one of these practices is a response to the same fear: I built it, and it's not what I wanted.

TDD answered that fear for functions.
BDD answered it for behaviours and shared language.
ADD answered it for teams and stakeholders. And when the builders became agents.
SDD answered it for intent — what did we actually decide to build? EDD answered it for quality — is the AI output actually good, and how do we know?

You don't have to pick one. You don't have to master all five. Pick the one that matches the failure you're most afraid of this week, and run it badly at first. Then run it less badly. The practices compound: every spec you write, every behaviour you articulate, every eval you fix, makes the next build cheaper to verify.

Code is cheap now. The scarce resource was never typing — it was knowing. These five practices are all just different languages for the same sentence:

Here's what I meant. Prove it.

References

The sources behind this article, in the order they were used:

1. Martin Fowler, Test Driven Development (updated Dec 2023). The standard summary of Red-Green-Refactor and its benefits. — https://martinfowler.com/bliki/TestDrivenDevelopment.html
2. Kent Beck, The Canonical TDD Post. Beck's own walkthrough of the TDD loop. — https://tidyfirst.substack.com/p/canon-tdd
3. Kent Beck, Test-Driven Development: By Example, Addison-Wesley, 2002. The original book.
4. Dan North, Introducing BDD (2006). The canonical essay: behaviour over test, the "should" template, Given/When/Then, ubiquitous language. — https://dannorth.net/blog/introducing-bdd/
5. Cucumber, BDD documentation. The Discovery / Formulation / Automation structure and Gherkin reference. — https://cucumber.io/docs/bdd/
6. BrowserStack, TDD vs BDD vs ATDD: Key Differences. The collaborative, pre-development nature of ATDD's acceptance criteria. — https://www.browserstack.com/guide/tdd-vs-bdd-vs-atdd
7. GeeksforGeeks, TDD vs BDD vs ATDD: Key Differences. — https://www.geeksforgeeks.org/software-testing/tdd-vs-bdd-vs-atdd-key-differences/
8. Software Testing Help, How Testers Are Involved in TDD, BDD & ATDD Techniques. — https://www.softwaretestinghelp.com/testers-in-tdd-bdd-atdd-techniques/
9. Ivan Turkovic, ADD: AI-Driven Development Methodology for Modern Engineers (Jan 2026). Cited for the disambiguation: "ADD" is also used for AI-Driven Development. — https://www.ivanturkovic.com/2026/01/25/ai-driven-development-add-methodology/
10. GitHub, Spec Kit — the open-source toolkit for spec-driven development with AI coding agents (140k+ stars as of Oct 2026). — https://github.com/github/spec-kit
11. GitHub Spec Kit Documentation — the SDD walkthrough: constitution → specify → plan → tasks → implement → converge. — https://github.github.com/spec-kit/
12. Fission-AI, OpenSpec — a lightweight, open-source spec framework for AI coding agents (73k+ stars); specs as first-class repo artifacts. — https://github.com/Fission-AI/OpenSpec · https://openspec.dev/
13. Hamel Husain & Shreya Shankar, AI Evals: Everything You Need to Know (Evals FAQ, updated Sep 2026). The reference for the EDD loop, error analysis, LLM-as-judge, the "generally no" answer on strict EDD, and the 100%-pass-rate warning. — https://hamel.dev/blog/posts/evals-faq/
14. Hamel Husain, Your AI Product Needs Evals. The practical guide to building domain-specific evaluation systems. — https://hamel.dev/blog/posts/evals/
15. Boming Xia, Qinghua Lu, Liming Zhu, Zhenchang Xing, Dehai Zhao, Hao Zhang, Evaluation-Driven Development and Operations of LLM Agents: A Process Model and Reference Architecture (arXiv:2411.13768). The academic treatment of EDD for LLM agents. — https://arxiv.org/abs/2411.13768
16. Gergely Orosz & Hamel Husain (The Pragmatic Engineer), A Pragmatic Guide to LLM Evals for Devs (Dec 2025). Industry perspective on evals as an engineering discipline. — https://newsletter.pragmaticengineer.com/p/evals
17. Exploding Gradients, RAGAS — open-source evaluation for RAG pipelines. — https://github.com/explodinggradients/ragas