mcpField
D
dx-devops-test-failures-analyze

dx-devops-test-failures-analyze

github.com/forcedotcom测试与质量1.1k5.1k 次安装1 天前更新
代码仓库

关于 dx-devops-test-failures-analyze

面向 Salesforce DevOps 的技能,可解读测试失败和 Code Analyzer 违规,并提出优先级改进建议。仅在用户明确要求并确认后,才创建跟踪用 WorkItem。

主要功能

  1. 01分类测试与分析器失败
  2. 02用通俗语言解释失败
  3. 03提出优先级改进建议
  4. 04按请求确认后创建 WorkItem

适用场景

  1. 01了解 Salesforce 测试运行失败
  2. 02审查 Code Analyzer 违规
  3. 03判断应修改测试还是生产代码
  4. 04将获批修复登记为 WorkItem

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/forcedotcom/sf-skills --skill dx-devops-test-failures-analyze

安装后在 Claude Code 中输入/dx-devops-test-failures-analyze确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
code-analyzer-violations.md
failure-categories.md
prerequisite-checks.md
work-item-creation.md

详细介绍

分析 DevOps Center 测试失败

解析测试失败或 Code Analyzer 违规负载,以通俗易懂的语言进行说明,提供按优先级排序的改进建议,并且仅在用户明确要求时创建可跟踪的修复工作项。第 1–2 部分仅进行推理(不执行写入);第 3 部分为可选写入操作,必须经过确认。

绝不要向用户暴露原始 JSON、堆栈跟踪或 Salesforce 内部错误代码。 始终将其转换为文件名、方法、行号和通俗描述。


前提条件

  • 第 1–2 部分(分析): 如果失败负载已在上下文中,则无需满足前提条件——这只是推理。如果需要自行获取负载,请运行前提条件检查(references/prerequisite-checks.md,前提条件 1–4),并通过 dx-devops-test-suite-run(其轮询步骤)获取执行结果。
  • 第 3 部分(工作项): 运行前提条件 1–4。还需要用于归档工作项的 DevopsProjectId 和受派人 OwnerId。参见 references/work-item-creation.md。

第 1 部分 — 分类并说明各项失败

确定失败类别,然后针对每项失败提取以下信息并转换成通俗描述:出错的文件/类、方法、行号、违反的规则或断言,以及修复方向(不编写代码)。如果存在多个类别,请按类别对失败进行分组。

类别说明
断言失败测试断言失败(预期值与实际值不匹配)
异常抛出了未处理的异常
Code Analyzer 违规违反了静态分析规则(例如 ApexCRUDViolation)
超时测试超过了执行时间限制
编译错误类未能通过编译

输出格式:

Test failure summary:

<N> failure(s) found:

1. [<Category>] `<ClassName>.cls` — `<methodName>()` at line <N>
   What happened: <plain-language description>
   Rule violated: <ruleName or assertion description>
   Fix direction: <plain-language suggestion>

完整的类别/模式表和 Code Analyzer 规则翻译,请参见:references/failure-categories.md 和 references/code-analyzer-violations.md。

空结果/无数据情况: 如果负载中没有失败或违规,请明确说明(例如:“提供的执行结果中未发现失败。”)并停止。不要捏造失败或建议。


第 2 部分 — 改进建议

请在执行完成并出现失败后运行此部分,不要针对静态源代码运行。对于每项失败的测试,请根据失败消息(主要信号)判断测试未处理的情况,然后提出具体、可执行的建议,并指出修复位置(测试代码或生产代码)。完整的“失败模式 → 建议”映射见 references/failure-categories.md。

Test improvement suggestions based on execution results:

`<testMethodName>()` — [Assertion Failure / Exception / etc.]
Failure: "<failure message>"
What this reveals: <plain-language explanation>
Suggestion: <specific, actionable recommendation>
Fix location: Test | Production code

Overall: <N> improvement(s) across <M> failed test(s).

不要重写测试——只说明需要更改什么以及原因。修复位置:生产代码表示健全的测试揭示了代码缺陷(应单独跟踪,不属于测试质量阻碍)。修复位置:测试表示需要加强测试(设置、断言、边界情况)。


第 3 部分 — 创建修复工作项(可选,仅按请求创建)

仅当用户希望创建修复工作项、记录补救措施或将失败指派给开发者时才触发。这是一个写入操作,必须经过确认。关于输入、主题/受派人/项目确认步骤、sf data create record --sobject WorkItem 调用以及错误处理,请遵循 references/work-item-creation.md。

使用 WorkItem(无命名空间)——在此组织版本中,DevopsWorkItem 不是受支持的 sObject。

如果组织中不存在 DevopsProject,请说明必须先设置项目才能创建工作项——不要捏造项目或继续操作。


相关技能

  • dx-devops-test-suite-run — 生成失败负载(通过其轮询步骤),供此技能使用。
  • dx-devops-test-suite-assignments-configure — 为测试失败的套件分配或强化配置。
  • platform-apex-generate / platform-apex-test-generate — 用于实际编写修复代码或新的测试类(不属于此处范围)。

评论

支持 Markdown