用途：这是一个测试驱动开发（TDD）知识库型技能，回答测试设计问题，重点给出“为什么”的推理，服务于测试设计决策。资料称其内容来自对 Kent Beck《Test-Driven Development: By Example》(2003) 与 Vladimir Khorikov《Unit Testing: Principles, Practices, and Patterns》(2020) 的通读提炼；另交叉引用 John Ousterhout《A Philosophy of Software Design》一处。
主要能力：按查询主题路由到 reference/ 下的参考文件，例如 TDD 周期与红绿重构对应 methodology-beck.md，良好测试与 3A、命名、参数化测试对应 test-design.md，mock/stub/fake 与 mock 最佳实践对应 test-doubles.md，重构与 Humble Object 对应 refactoring-under-test.md，好测试四支柱与脆弱测试对应 four-pillars-khorikov.md，覆盖率指标对应 code-coverage-khorikov.md，经典学派与伦敦学派对应 classical-vs-london-khorikov.md，可观察行为与实现细节对应 observable-behavior-khorikov.md，测试风格、可测架构、集成测试、反模式及 Beck 的 Money 与 xUnit 示例各有对应文件。命名约定：{concept}.md 为多位作者共有概念，{concept}-{author}.md 为单一作者实质覆盖的内容。
使用方式：先加载最相关的文件；仅当首个文件不能完整回答时再加载第二个。资料还提供无需加载文件的快速判断指南，例如：除非是可信第三方代码或简单代码（2x2 矩阵左下角：低复杂度、少量协作者），否则应写测试；仅对非托管依赖（消息总线、SMTP）使用 mock，托管依赖（数据库）用真实实例；自信时用 Obvious Implementation，被红色结果意外时退回 Fake It；若测试需要超过 3 处改动才能工作，先写更小的 Child Test；测试应写在前面；优先输出型测试，其次状态型，通信型仅用于有可见副作用的系统间；高复杂度且多协作者应拆分（Humble Object）；只为需要 mock 的非托管依赖引入接口；有领域意义的前置条件应测试，纯技术性的不必；读操作的测试门槛高于写操作；领域模型需要触发外部通知而不依赖进程外依赖时用领域事件；测试脆弱通常因其耦合实现细节。
适用场景：编写或评审单元测试、决定测试粒度与风格、处理 mock 与依赖、判断覆盖率含义、设计可测架构时参考。
限制：该技能只提供知识（测试决策背后的 WHY），不提供工作流（如何运行测试）。运行、过滤或脚手架测试应使用项目自身的测试工具、约定与工作流技能。资料未说明具体安装方式、收费、平台或效果。