$ loading_
帮助开发者编写关注行为、抗重构且可验证修复意图的高质量测试。
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "test-discipline" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/devsquad-copilot/main/.github/plugins/devsquad/skills/test-discipline/SKILL.md 2. 保存为 ~/.claude/skills/test-discipline/SKILL.md 3. 装好后重载技能，告诉我可以用了
请为这个新功能设计并编写测试，要求测试通过公共接口验证用户可观察行为，避免依赖内部实现细节，并说明每个测试覆盖的意图。
一组面向行为的测试用例及简要说明，覆盖主要功能路径且不依赖内部实现。
下面是一个已定位根因并准备修复的缺陷。请先编写能稳定复现问题的回归测试，再给出修复代码，确保测试从失败到通过，并说明测试为何能防止问题再次发生。
先失败后通过的回归测试与对应修复方案，并附上防回归说明。
请审查这组测试的质量，重点检查它们是否验证行为意图、是否过度耦合实现细节、是否具有抗重构性，并提出可执行的改进建议。
一份测试质量评审意见，指出问题测试、风险点及具体改进方向。
Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests should not break unless behavior changes. A good test reads like a specification.
Use TDD strategically, not dogmatically. The goal is high-quality tests that verify intent — the ordering of when tests are written is a means to that end, not the end itself.
Test-first (red-green-refactor) works best when:
Design-first-then-test works best when:
In both approaches, the quality criteria for the resulting tests are identical.
Regardless of test-first or design-first, deliver work in vertical slices — thin end-to-end paths through all layers.
Anti-pattern: horizontal slicing
Writing all tests first (or all of one layer first), then all implementation. This produces tests that verify imagined behavior and delays integration feedback.
AVOID (horizontal):
All tests → All implementation
All models → All services → All endpoints
PREFER (vertical):
Slice 1: User can create an order (all layers, happy path)
Slice 2: Order validates required fields (error handling)
Slice 3: Order calculates totals (business logic)
The first slice should be a tracer bullet: a thin end-to-end path that proves the architecture works.
Every test must satisfy these criteria regardless of when it was written:
| Criterion | Check |
|---|---|
| Behavior-focused | Tests what the system does, not how it does it |
| Public interface only | Uses the same API that callers use |
| Refactor-resistant | Would survive internal restructuring without changes |
| Independent | Does not depend on other tests or test execution order |
| Deterministic | Same result every run, no timing dependencies |
| Readable | Test name describes the behavior being verified |
For unit test rules, integration test rules, and test doubles hierarchy, follow coding-guidelines.md (always in context). This skill focuses on what coding-guidelines does not cover: the decision framework, per-task procedure, quality criteria, and anti-patterns.
Good tests exercise real code paths through public APIs. They describe what the system does, not how. They read like a specification: "user can checkout with valid cart" tells you exactly what capability exists.
Bad tests are coupled to implementation:
…
帮助你创建、切换并检查代码分支，确保实现前遵循正确分支策略。
沉淀并查询代码库经验教训，帮助开发、验证与评审减少重复踩坑。