SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场ln-404-test-executor

ln-404-test-executor

测试与质量

查看项目

更新于 10-15 15:27

技能介绍

用途

ln-404-test-executor 是一个 L3 Worker 技能，用于执行单个 Story 的最终测试任务（标签为“tests”），将其从 Todo 推进到 To Review。它只处理测试任务；其他任务应交给 ln-401。

主要能力

  • 遵循 11 段测试任务计划，涵盖 E2E、集成、单元测试，以及基础设施、文档和清理部分。
  • 施加基于风险的约束：优先级 ≥15 的场景需覆盖；每个测试需通过有用性标准；不编写框架、数据库、库或性能测试。
  • 仅针对当前任务更新跟踪器与看板：Todo → In Progress → To Review。
  • 支持 Hex-line 加速（如可用）：在读取测试目标前使用 outline(file_path)；使用窄范围 inspect_path(path=<相关测试目录>) 了解测试结构；如需完整清单可显式使用 max_entries=0。先用 grep_search(output_mode="summary") 查找测试/辅助/夹具，再按需升级到 output_mode="content", edit_ready=true；allow_large_output=true 仅作显式覆盖。测试/代码/配置文件优先使用 read_file() 与 edit_file()；常规检查保持 read_file() 发现模式，编辑前使用 read_file(edit_ready=true, verbosity="full")。交接前使用 verify() 与 changes()。仅在 hex-line 不可用时回退到内置 Read/Edit。

使用方式

输入：taskId（必填），来源为 args、父 Story、看板或用户，表示要执行的测试任务。解析方式遵循 Task Resolution Chain，状态过滤为 Todo（标签：tests）。

强制读取的参考文件包括：references/environment_state_contract.md、references/storage_mode_detection.md、references/tracker_provider_contract.md、references/input_resolution_pattern.md、references/ci_tool_detection.md、references/mcp_tool_preferences.md、references/goal_articulation_gate.md、references/code_efficiency_criterion.md、references/coordinator_summary_contract.md、references/worker_runtime_contract.md、references/task_worker_runtime_contract.md、references/research_tool_fallback.md。

任务存储模式：从 Task Management → Provider 提取 task_provider（linear | github | file）。本技能使用的跟踪器操作：getTask、getStory、updateStatus（Todo → In Progress → To Review）、addComment（测试结果）。传输绑定见 references/provider_file.md、references/provider_github.md、references/provider_linear.md。

工作流（简要）：

  1. 按指南运行 Task Resolution Chain 解析 taskId（状态过滤：[Todo, label: tests]）。
  2. 通过配置的跟踪器提供者获取完整测试任务描述（getTask）；阅读关联指南/手册/ADR/研究；查看父 Story（getStory）及提供的手动测试结果。 2b. 目标门：读取 references/goal_articulation_gate.md，说明这些测试的真实目标（需验证哪项业务行为，而非“编写测试”）。非目标：测试基础设施或框架行为而非业务逻辑。隐藏约束：实现变更可能破坏哪些现有测试。
  3. 阅读环境文档：docs/project/infrastructure.md（服务器 IP、端口、服务端点）；docs/project/runbook.md（测试环境搭建、Docker 命令、测试执行前提）。使用运行手册中的确切命令。
  4. 验证计划：检查优先级 ≥15 覆盖与有用性标准；确保聚焦业务流（无仅基础设施测试）。
  5. 开始工作：通过配置的跟踪器提供者设置任务为 In Progress（updateStatus）；在看板中移动。
  6. 实现并运行：读取 references/code_efficiency_criterion.md；按计划编写/更新测试；复用现有夹具/辅助；运行测试；修复失败的现有测试；按需更新基础设施/文档部分。交接前验证 3 项效率自检（尤其是：复用夹具而非重复搭建）。
  7. 完成：确保计数/优先级仍在限制内；设置任务为 To Review；在看板中移动；添加评论总结覆盖范围、运行的命令及任何偏差。

适用场景

适用于执行单个 Story 的最终测试任务（标签“tests”），从 Todo 到 To Review 的推进。不适用于实现任务。

限制与关键规则

  • 仅单任务；不批量更新。
  • 不标记 Done；由评审者批准。任务必须以 To Review 结束。
  • 语言（EN/RU）与任务保持一致。
  • 不编写框架/库/数据库/性能/负载测试；聚焦业务逻辑正确性（而非基础设施吞吐量）。
  • 遵守限制与优先级；若违反，停止并返回发现。
  • 不提交。所有改动保持未提交——由评审者审查并提交。

运行时摘要产物

强制读取 references/coordinator_summary_contract.md、references/worker_runtime_contract.md、references/task_worker_runtime_contract.md。共享契约：emit summary_kind=task-status；standalone 模式省略 runId 与 summaryArtifactPath；managed 模式在 worker 写入已验证摘要前传入 runId 与确切的 summaryArtifactPath。Monitor（2.1.98+）：对于预期超过 30 秒的测试/覆盖率命令，使用 Monitor。回退：Bash(run_in_background=true)。

完成定义

  • 任务被识别为测试任务并设置为 In Progress；看板已更新。
  • 计划已验证（优先级/限制）且指南已读。
  • 测试已实现/更新并执行；现有失败已修复。
  • 按任务计划应用文档/基础设施更新。
  • 任务设置为 To Review；看板已移动；添加摘要评论，包含命令与覆盖范围。
  • 运行时摘要产物写入共享 task-status 位置。

测试失败分析协议

关键：当新编写的测试失败时，先停止并分析，再更改任何内容（失败的新测试往往表明实现缺陷，而非测试问题——盲目修复会掩盖根因）。

步骤 1：验证测试正确性

  • 测试是否与 AC 要求完全匹配？（Story 中的 Given/When/Then）
  • 预期值是否符合业务逻辑？
  • 如不确定：查询 ref_search_documentation(query="[domain] expected behavior")

步骤 2：决策

  • 测试匹配 AC？是 → 代码缺陷 → 修复实现，而非测试。否 → 测试错误 → 修复测试断言。不确定 → 强制：查询 MCP Ref 并在更改前询问用户。

步骤 3：在跟踪器评论中记录（addComment） "Test [name] failed. Analysis: [test correct / test wrong]. Action: [fixed code / fixed test]. Reason: [justification]"

红旗（需用户确认）：

  • ⚠️ 更改断言以匹配实际输出（“让测试变绿”）
  • ⚠️ 移除“不工作”的测试用例
  • ⚠️ 弱化期望（例如用 toContain 代替 toEqual）

绿灯（可安全继续）：

  • ✅ 修复测试搭建/模拟数据中的拼写错误
  • ✅ 修复代码以匹配 AC 要求
  • ✅ 添加缺失的测试搭建步骤

测试编写原则

  1. 严格断言——任何不匹配即失败 默认使用精确匹配断言：精确相等检查（优先）vs 部分/子串匹配（避免，除非有理由）；精确长度检查 vs “有任意长度”检查；完整对象比较 vs 部分对象匹配；精确类型检查 vs 真值/假值检查。禁止 WARN 级断言——测试要么 PASS 要么 FAIL，无警告。

  2. 基于期望的确定性输出测试 对于确定性响应（API、转换）：对复杂确定性输出使用快照/黄金文件测试；比较实际输出与期望参考文件；比较前规范化动态数据（时间戳 → 固定值，UUID → 占位符）。

  3. 黄金法则 “如果你知道期望值，就断言精确值。”禁止：当精确值已知时，使用宽松断言“让测试通过”。

参考文件

  • 环境状态：references/environment_state_contract.md
  • 存储模式操作：references/storage_mode_detection.md
  • 看板格式：docs/tasks/kanban_board.md
  • 强制读取：references/research_tool_fallback.md

版本：3.2.0 最后更新：2026-01-15