test-driven-development

Agent Skills › odysseus-dev/odysseus › test-driven-development

test-driven-development

GitHub

指导通过红-绿-重构循环实现功能或修复缺陷。先写最小回归测试复现问题，确保失败后修改代码使其通过，最后审查变更并验证测试套件。

resources/skills/general/test-driven-development/SKILL.md odysseus-dev/odysseus

Trigger Scenarios

需要编写回归测试以定义预期行为修复 bug 或实现新功能时希望防止回归

Install

npx skills add odysseus-dev/odysseus --skill test-driven-development -g -y

More Options

Non-standard path

npx skills add https://github.com/odysseus-dev/odysseus/tree/dev/resources/skills/general/test-driven-development -g -y

Use without installing

npx skills use odysseus-dev/odysseus@test-driven-development

指定 Agent (Claude Code)

npx skills add odysseus-dev/odysseus --skill test-driven-development -a claude-code -g -y

安装 repo 全部 skill

npx skills add odysseus-dev/odysseus --all -g -y

预览 repo 内 skill

npx skills add odysseus-dev/odysseus --list

SKILL.md

Frontmatter

{
    "name": "test-driven-development",
    "tags": [
        "tdd",
        "testing",
        "debugging",
        "red-green-refactor"
    ],
    "owner": "",
    "source": "builtin",
    "status": "published",
    "created": "2026-08-18T00:00:00Z",
    "version": "1.0.0",
    "category": "general",
    "confidence": 1,
    "description": "Build or fix software with a focused red-green-refactor loop"
}

When to Use

Use when implementing a feature, fixing a bug, or changing behavior where a regression test can define the expected result. Prefer this workflow for parser, routing, agent-loop, and UI behavior changes.

Procedure

Inspect the relevant code, existing tests, and local conventions before editing.
Write the smallest regression test that demonstrates the requested behavior or reproduces the bug.
Run that test and confirm it fails for the expected reason, not because the test setup is broken.
Make the smallest production change that makes the test pass.
Run the focused test again, then run the surrounding module suite.
Review the diff for unrelated changes, brittle assertions, hidden state, and missing error paths.
Report the tests run and any remaining coverage or environment limits.

Pitfalls

Do not write a test that only mirrors the implementation; assert the user-visible contract.
Do not weaken an assertion just to make a failing test pass.
Do not skip the focused failing-test step when the behavior is observable in a local test.
Keep network, filesystem, and model calls deterministic with fakes or fixtures unless the integration itself is under test.

Verification

The new regression test fails before the fix and passes after it.
The relevant focused suite passes.
The broader suite passes or its failure is explained with evidence.
The final diff contains the test and the production change needed for the same behavior.