ECC 智能体工程环境中的测试规范：从 .kiro/steering/testing.md 看 80% 覆盖率与 TDD 工作流的落地

ECC 智能体工程环境中的测试规范从 .kiro/steering/testing.md 看 80% 覆盖率与 TDD 工作流的落地【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC本文围绕仓库内.kiro/steering/testing.mdEverything Claude Code 移植到 Kiro 的 steering 规范文件展开剖析 ECC 如何在每个 AI 辅助开发会话中强制落实“最低 80% 测试覆盖率 三层次测试类型 先写测试再写实现的 TDD 工作流”。读完你可以理解这类“常驻 steering 规则”的运作机制掌握单元/集成/E2E 三层测试的划分标准、RED–GREEN–IMPROVE 的完整操作顺序以及如何借助配套的tdd-guideAgent、tdd-workflowSkill 与质量门禁 Hook 把测试纪律变成可自动执行的项目基础设施。testing.md位于仓库的.kiro/steering/目录下是 ECC 为 KiroKiro IDE 与kiro-cli准备的 22 个 steering 文件之一。它的 YAML frontmatter 声明了inclusion: auto含义是一旦通过 install.sh 安装到目标项目的.kiro/目录该文件就会在每一次开发会话中被自动加载成为持续生效的测试约束而不是一份需要手动查阅的静态文档。认识 testing.md一段“时刻在场”的测试约束先看这份文件的完整骨架它只有 4 个 H2 小节却覆盖了从“质量底线”到“失败响应”再到“Agent 协同”的完整闭环小节核心内容落点Minimum Test Coverage: 80%覆盖率底线 三类必测类型质量阈值Test-Driven DevelopmentMANDATORY 的六步工作流开发过程纪律Troubleshooting Test Failures失败时的排查四步法失败响应协议Agent Support何时主动调用tdd-guide人机协同分工这类文件的作用原理是“规则即上下文”。按 .kiro/README.md 的说明inclusion: auto的 steering 文件无需任何手动触发安装后即刻生效tdd-guide的语义被浓缩在 frontmatter 的 description 里供 Agent 在做意图识别时检索到“新功能/修 Bug/重构需要先写测试并保证 80% 覆盖率”这一约束。覆盖率底线与三层测试类型ALL required测试规范第一条给出了可量化的质量下限最低 80% 覆盖率。与之配套的三类测试被标记为ALL required即全部必选不是可选加分项Unit Tests单元测试—— 覆盖独立的函数、工具方法、组件逻辑重点是“在隔离环境下验证单个行为单元”Integration Tests集成测试—— 覆盖 API 端点、数据库操作、服务之间的交互验证各模块拼装后的真实协作E2E Tests端到端测试—— 覆盖关键用户流测试框架按语言生态选择如 Web 场景用 Playwright / Cypress。关于“80%”的具体口径tdd-guide.md 给出了更精确的定义验证时branches、functions、lines、statements四项维度都要达到 80%对应命令为npm test npm run test:coverage # Required: 80% branches, functions, lines, statements如果项目使用 Jest 体系可在 tdd-workflow 技能 中看到如何把这些阈值固化进package.json的coverageThresholds{ jest: { coverageThresholds: { global: { branches: 80, functions: 80, lines: 80, statements: 80 } } } }把阈值写进工具配置的意义在于覆盖率不达标时测试命令会以非零码失败从而让质量门禁见后文 quality-gate可以在 CI/提交前拦截住“低覆盖率的‘假绿’”。强制 TDD六步标准工作流原文档用 “MANDATORY workflow” 强调了这一过程的不可协商性六个步骤完整复刻如下先写测试RED先写一个描述预期行为的失败测试运行测试验证它确实失败FAIL只有先看到失败才能证明测试真的在守护行为而非空转写最小实现GREEN只写足够让测试通过的代码不做多余设计运行测试验证它通过PASS重构IMPROVE去除重复、改善命名、优化性能但全程保持测试绿色验证覆盖率80%跑覆盖率报告确认达到阈值。这与 tdd-guide Agent 内部规定的 RED–GREEN–Refactor 循环完全一致——steering 文件定义“必须做什么”Agent 负责“带着人把每一步走完”。值得补充的是同一份 Agent 配置还在v1.8 Eval-Driven TDD Addendum中把 TDD 与“评估驱动开发”打通形成对 LLM 应用开发更适用的变体实现前先定义 capability regression evals能力评估与回归评估运行基线并记录失败特征failure signatures实现最小可通过变更重跑测试与 evals汇报pass1与pass3面向发布的关键路径在合入前应以pass^3稳定性为目标。从 ECC 的设计意图看TDD 在这里不仅是测试方法论更被当作让 Agent 代码产出可验证、可回归的质量保险——先写测试等于先把“验收标准”显式化避免智能体凭直觉实现后偏离需求。测试失败时的排查协议原文档给出的失败排查四步顺序值得原样保留因为它体现了一种“先自查、后改动”的克制心态使用tdd-guideAgent把失败的上下文交给 TDD 专家 Agent而不是自己盲目猜测检查测试隔离性test isolation测试之间是否存在共享状态导致的相互依赖这常常是“单独跑通过、一起跑失败”的元凶验证 mock 是否正确外部依赖如数据库、Redis、第三方 API的 mock 是否和真实行为一致修实现而不是修测试除非测试本身写错了测试是行为契约实现必须迁就契约只有在测试断言本身错误时才允许改测试。配合这套协议tdd-guide Agent 预先枚举了 8 类必须测试的边界场景可作为排查时反向检查的清单Null/Undefined输入空数组 / 字符串非法类型传入边界值min/max错误路径网络失败、数据库错误竞态条件并发操作大数据量10k 条目的性能表现特殊字符Unicode、emoji、SQL 注入字符同时它也列出了要规避的反模式测实现细节而非用户可见行为、测试之间共享状态、断言过少导致“通过但没有验证任何事”、不 mock 外部依赖Supabase、Redis、OpenAI 等。这些约束与 tdd-workflow 技能 中“测试实现细节 vs 测试用户可见行为”“脆弱的 CSS 选择器 vs 语义化选择器”“无隔离的顺序依赖 vs 每个测试自建数据”三组正反对照一脉相承。从规则到执行Agent / Skill / Hook 的三重支撑体系testing.md本身只是声明式约束真正让它“跑起来”的是仓库中同一主题下的三件配套资产。它们共同构成了一条从理念到机器可执行的链路1.tdd-guideAgentTDD 方法论执行者在 .kiro/agents/tdd-guide.md 与对应的 tdd-guide.json 中Agent 被定位为“write-tests-first 方法论的强制者”并配有quality checklist所有公共函数有单元测试、所有 API 端点有集成测试、关键用户流有 E2E 测试、边界与错误路径已覆盖、外部依赖已 mock、测试相互独立、断言具体有效、覆盖率 80%。tdd-guide的调用时机在原文档中被特别标注为PROACTIVELY主动调用写新功能、修 Bug、做重构时不应等规则被违反才想起它。2.tdd-workflowSkill可复用的分步操作手册tdd-workflow 技能 把 TDD 展开成从“用户旅程As a … I want to … so that …”起步、到“为每个旅程生成测试用例”、再到“跑失败 → 最小实现 → 跑通过 → 重构 → 验证覆盖率”的七步可执行流程并附带可直接照抄的 Jest/Vitest 组件测试、Next.js API 集成测试、Playwright E2E 测试模板以及 Supabase/Redis/OpenAI 三种外部服务的 mock 写法。它还给出了推荐的测试文件组织结构src/ ├── components/ │ ├── Button/ │ │ ├── Button.tsx │ │ ├── Button.test.tsx # Unit tests │ │ └── Button.stories.tsx # Storybook ├── app/api/markets/ │ ├── route.ts │ └── route.test.ts # Integration tests └── e2e/ ├── markets.spec.ts # E2E tests └── auth.spec.ts3. Hook在正确时机自动提醒与把关IDE Hook 把“纪律”从“有人记得”升级为“机器自动触发”。与测试主题直接相关的两个 hook 位于.kiro/hooks/下tdd-reminder.kiro.hook监听fileCreated当新建.ts/.tsx源文件时触发askAgent提示“这个文件是否需要对应测试若含应测逻辑请按 TDD 原则建议创建测试文件”——在产生未测代码的第一时间植入测试意识quality-gate.kiro.hookuserTriggered类型手动从 Agent Hooks 面板点击即执行bash .kiro/scripts/quality-gate.sh把“提交前自检”做成一键操作。4.quality-gate.sh把规则落成可判定的脚本质量门禁的底层实现是 .kiro/scripts/quality-gate.sh。它对测试规范的执行具有三重工程意义包管理器自适应按pnpm-lock.yaml → yarn.lock → bun.lock(b) → package-lock.json → 环境命令的顺序探测pnpm/yarn/bun/npm避免硬编码能力感知的优雅降级没有package.json的 build/test 脚本、没有 tsconfig 或 pyright/mypy 配置、没有 linter 配置时对应检查项会以○标记跳过而不是整体崩溃——例如 JS/TS 项目走$PM run testPython 项目含pyproject.toml pytest走pytestGo 项目走go test ./...明确的退出码语义任何一项失败都输出✗明细并最终以exit 1结束从而能被 CI 或 pre-commit 正确拦截全部通过输出 “Quality gate: PASSED”。一个典型的门禁输出形如Package manager: npm ✓ Build ✓ Type check ✓ Lint (ESLint) ✓ Tests ───────────────────────────────────── Results: 4 passed, 0 failed, 0 skipped (4 total) Quality gate: PASSED如何在你的 Kiro 项目中启用这套测试规范因为仓库的.kiro/是一份完整的、可移植的 Kiro 工作流包启用它的方式就是整包安装。按 .kiro/README.md 与 install.sh# 在项目根目录下执行 .kiro/install.sh 即可装入当前项目 ./.kiro/install.sh # 或装入指定项目目录 ./.kiro/install.sh /path/to/your/project # 或全局安装作用于所有 Kiro 项目 ./.kiro/install.sh ~安装器采用非破坏性复制目标已存在的同名文件不会被覆盖因此你后续对 steering / agent / skill / hook 的自定义在重复安装后依然安全install.sh 中通过逐个判断if [ ! -f ... ]实现。安装完成后steering 文件含本主题的testing.md随autoinclusion 自动加载无需任何操作在 IDE 会话中输入/打开技能菜单选tdd-workflow即进入测试先行流程在 CLI 会话中可通过/agent swap切换到tdd-guide或直接以kiro-cli --agent tdd-guide启动带 TDD 约束的会话在 Agent Hooks 面板中开启tdd-reminder并在提交前点击quality-gate触发全量质量检查。.kiro/README.md推荐的“Recommended Workflow”中TDD 位于规划之后、编码之前先用planner拆解功能随后立即调用tdd-workflow/tdd-guide让测试先行写完代码切到code-reviewer审查提交前触发quality-gate。这与本 steering 文档中“write tests first 80% 覆盖 失败先自查”的三段式纪律一一咬合。小结steering 式测试规范的工程价值从 testing.md 这一份不足 40 行的 steering 文件出发可以看到 ECC 在工程化测试纪律上的完整设计用常驻上下文steering声明底线用专家 Agenttdd-guide承接执行用技能tdd-workflow提供可复现的步骤与模板用 Hook 脚本tdd-reminder、quality-gate把把关时机自动化。四者叠加后“80% 覆盖率 三层测试 先红后绿”不再依赖个人自觉而成为 AI 辅助开发环境中默认启用的质量基础设施——这正是“规则即上下文、上下文即执行力”这一 agentic 工程思路在质量保障侧的典型落点。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考