用途：这是一套语言无关的测试原则，适用于各类测试框架与语言，帮助开发者写出有效、可维护、能支撑重构的测试。
主要能力：
- 核心原则：测试行为而非实现，测试应在重构后依然存活。
- 测试优先工作流（Canon TDD）：先列测试清单，再写失败测试，最小实现使其通过，随后重构，循环直至清单清空。
- 明确何时用 TDD：核心领域逻辑、算法、业务规则、生产代码、AI 辅助开发适用；UI 原型、探索性、需求模糊时不适用。
- 测试边界：单元测试针对纯函数与业务逻辑，集成测试针对模块交互与 API 契约，E2E 只覆盖关键用户旅程与关键错误。
- Mock 策略：外部 API、网络、非确定性行为必须 mock；自有领域逻辑与内部协作者绝不 mock；单测中 mock 超过 3 个是耦合实现的危险信号。
- 测试隔离：测试间不共享可变状态、不依赖执行顺序，可安全并行。
- AAA 结构：Arrange、Act、Assert 三阶段清晰分隔，每个测试一个行为。
- 命名：采用“should [预期行为] when [条件]”式描述性句子。
- 覆盖率哲学：重视关键路径、边界与错误处理，不追逐百分比。
- 排除项为最后手段：优先尝试导出函数、重构、复用现有模式，再考虑覆盖率排除、ESLint 禁用、类型断言或跳过测试，并附原因注释。
- 常见测试坏味道：mock 过多、断言脆弱、意图不清、测试实现细节、不稳定、过慢、单个巨型测试、魔法值。
- 质量优先级：可读性高于 DRY，测试即文档。
- 集成测试模式：API 路由、数据库（真实测试库加事务回滚）、Webhook 端到端、Convex 集成测试等示例。
使用方式：在编写测试前先明确要验证的唯一行为、区分行为与实现、找出最值得先测的失败场景；按 AAA 组织，遵循命名规范，控制 mock 数量，必要时用真实测试数据库与事务回滚保证隔离。
适用场景：生产代码的单元、集成与端到端测试，尤其是核心业务逻辑、错误处理与边界条件。
限制：资料未提供具体安装命令、依赖版本、收费或平台信息；部分示例涉及特定框架（如 Convex、Stripe），需结合自身技术栈调整。