pragmatic-testing 是一个指导开发者如何务实地编写和维护测试的技能，核心理念是“测试是为了让我们能改产品并继续发布”。它强调够用而非完美，不必为每个 if 分支写测试，先用宽笔刷覆盖整体，再用细笔刷处理边界。资料中的示例使用 Swift，但规则适用于任何语言。
用途 该技能用于在新增、修改、审查或精简测试之前加载，帮助回答四个问题：是否值得写这个测试、它应断言什么、应使用哪种测试替身，以及一次改动需要多少个测试。
主要能力
- 值得写吗检查：写测试前回答“它捕获哪个缺陷”（须是一行可想象的错误，不能是“有人删除函数”）、“删掉它什么会坏着发布”、“它能否在保持行为不变的重构后存活”。
- 期望值来自产品规则：期望值写成从产品规则得来的字面量，输入放在边界上，规则不明显时加注释；不得由被测代码、被测格式化器或被测分支逻辑推导期望值。
- 每个契约只有一个所有者：在拥有该规则的最低层测试一次，层级从低到高为领域逻辑、状态或 presenter、view model；高层只写一个接线测试。
- 测试替身选择：按测试问题选最便宜的替身，包括生成的 mock、薄包装、每个协议一个可控 fake、以及针对实现行为的真实集成测试。
- 自由打桩，只验证效果：只验证用户或系统可观察的效果，如删除、写文件、购买、网络变更、分析事件、导航；不验证读取和获取的调用次数。
- 测试预算：多数行为改动 1 至 3 个测试，写第四个前说明理由；并发与顺序、持久化与恢复、金钱与访问控制不设上限；纯接线、单行透传、枚举复述等可以不写测试，但须指明兜底的现有测试或编译器检查。
- 缺陷复现：在拥有该缺陷的层写聚焦测试，先在未修复代码上看到它因报告的原因失败，再修复，并明确决定测试的去留。
- 坏味道清单：列出 mock 返回什么就断言什么、生产逻辑计算期望值、替身重新实现产品逻辑、无法失败的断言、读取调用次数、近乎相同的测试、sleep 后断言等常见问题及修复建议。
- 审计模式：先报告后修改，为每个候选项给出证据；保留竞态与挂起证明、唯一的文件系统或数据库失败模式测试、真实缺陷回归、可观察顺序测试；若弱测试是唯一测试则重写而非删除。
- 证明精简有效：删除、合并或重写测试后，用每个函数的覆盖率前后对比和变异测试证明剩余测试仍能捕获旧测试捕获的问题，且精简者不得自评。
使用方式 资料将其描述为在添加、修改、审查或精简测试之前加载的技能，具体安装命令暂未提供。
适用场景 适用于日常开发中的测试编写与审查、遗留测试清理、缺陷复现、测试替身治理，以及需要评估测试预算和覆盖率的团队实践。
限制 资料未提供具体安装命令、支持的平台与工具链范围、收费或价格信息；示例语言为 Swift，其他语言的应用细节暂未提供。