用途：在决定测试范围、编写新功能测试、评审测试质量或收到“加点测试”的模糊要求时启用，也可用于判断现有测试是否真正有价值。核心理念是“写测试，别太多，以集成测试为主”：自动化测试应支持自信重构、充当文档并捕获回归。判断标准：功能坏掉时测试会失败才有价值；只在重构时失败则是在测实现细节。
主要能力：提出分层策略——静态分析（TypeScript、ESLint）作为第一道防线；单元测试覆盖纯函数与算法；集成测试是重点，测试用户实际体验的行为；E2E（Playwright）只保留关键用户旅程。强调 Arrange-Act-Assert 结构、测试命名说明会坏什么、每个测试只有一个失败理由。信任边界（表单、KV、缓存、catch 块）需同时测有效与无效数据。
必要的测试原则：优先使用可访问查询（getByRole、getByLabelText），避免过度 mock，只在外部边界 mock；不要测琐碎代码、框架行为、实现细节、一次性脚本或易变原型；覆盖率只是信号而非目标；快照不适合易变内容。
使用方式：按工作流先理解功能对用户的价值，找出关键路径，先写集成测试，再为复杂逻辑补单元测试；测试文件靠近代码（如 src/lib/features/auth/login.test.ts）；开发时运行 npx vitest，CI 用 npx vitest run。缺陷应转化为回归测试。若需 Vitest 语法、mock 模式或 SvelteKit 测试写法，应配合 javascript-testing 技能；写作风格参考 grove-documentation；提交前运行 lint 与类型检查。
适用场景：新功能、缺陷修复、重构、API 端点、UI 组件和关键用户流程等。限制：资料未提供具体安装命令、价格或平台信息，也未给出可运行的完整示例；部分实现细节需结合 javascript-testing 技能。