moai-workflow-testing

开发工作流专家

快速参考

统一的开发工作流，结合 DDD（领域驱动开发）测试、调试指南、性能优化、自动化代码审查和 CI/CD 质量门禁。强调通过特征测试，在重构过程中保留行为。

核心能力：

• DDD 测试：特征测试（遗留项目）+ 规格测试（全新项目）+ 行为快照
• AI 驱动的调试：错误分析、分类、候选解决方案
• 性能优化：性能分析、瓶颈检测、优化建议
• 自动化代码审查：TRUST 5 框架验证
• PR 代码审查：多 Agent 模式（Haiku 资格判断 + 5 个 Sonnet 并行审查员）
• 质量保证：集成 CI/CD 和质量门禁

工作流进程：调试 → 重构 → 优化 → 审查 → 测试 → 性能分析

适用场景：

• 完整开发生命周期管理
• 质量保证和 CI/CD 集成
• 多语言和性能关键型项目
• 降低技术债务
• PR 代码审查自动化

---

实施指南

核心概念

五个集成组件构成该工作流：

• AI 驱动的调试：错误分类（语法/运行时/逻辑/集成/性能）并按可能性排列候选解决方案
• 智能重构：结合复杂度指标和风险评估分析技术债务
• 性能优化：CPU/内存/IO/网络性能分析及优化策略
• DDD 测试管理：遗留项目的特征测试（PRESERVE 阶段）+ 全新项目的规格测试 + TRUST 5 验证
• 自动化代码审查：TRUST 5 框架及可执行的建议

TRUST 5 框架

包含五个维度的质量评估模型：

• 可测试性：纯函数、可注入依赖、模块化设计
• 可读性：描述性名称、逻辑结构、复杂度说明
• 可理解性：清晰的业务逻辑、恰当的抽象、明确的概念
• 安全性：输入验证、密钥管理、符合 OWASP 规范（注入/XSS/CSRF）
• 透明性：全面的错误处理、结构化日志、可追踪的问题

总分：加权平均分，并覆盖关键维度（安全性/可测试性问题不能被其他维度掩盖）。

完整评估标准请参阅 TRUST 5 详细维度和评分。

DDD 测试流程

遗留代码（PRESERVE 阶段）：

1. 编写特征测试，记录当前行为（而非期望行为）
2. 按领域概念组织测试，以显现领域边界
3. 对复杂场景使用行为快照作为回归保护
4. 验证基线：任何更改之前，所有特征测试都必须通过
5. 持续运行测试并进行重构
6. 重构后运行 TRUST 5 验证

全新开发：

1. 根据领域需求推导规格测试（每项测试对应一条业务规则）
2. 按聚合、实体、值对象组织测试（DDD 通用语言）
3. 使用业务语言描述行为，而非实现细节
4. 编写实现以满足规格要求
5. 使用集成测试验证（领域交互 + 不变量）
6. 执行 TRUST 5 验证

调试、重构、性能工作流

三者均遵循 6 步模式：捕获/分析 → 分类 → 确定候选方案 → 应用 → 验证 → 记录。

详细流程表请参阅调试/重构/性能分步演练。

代码审查流程

1. 扫描代码库，确定审查目标
2. 对每个文件应用 TRUST 5 框架
3. 识别关键问题
4. 计算每个文件的分数和汇总分数
5. 生成按优先级排序的建议
6. 创建包含改进路线图的摘要报告

PR 代码审查（多 Agent 模式）

5 步多 Agent 流水线：

1. 资格检查（Haiku）：跳过已关闭、草稿、已审查或过于简单的 PR
2. 收集上下文：查找每个已修改目录中的 AGENTS.md + 总结 PR
3. 并行审查（5 个 Sonnet Agent）：检查是否符合 AGENTS.md / 明显错误 / git blame / 之前的评论 / 代码注释合规性
4. 置信度评分（0-100）：0=误报，25=有一定把握，50=中等把握，75=高度把握，100=确定
5. 筛选与报告：删除置信度低于 80 的问题，通过 gh CLI 发布，附上文件 / 行号 / 提交链接

请参阅 PR 审查多 Agent 架构与输出格式，了解 Agent 角色详情和输出示例。

多语言支持

按语言提供工具链映射（Python：pytest+ruff+bandit；JS/TS：Jest+ESLint+npm audit；Go：go test+staticcheck+gosec；Rust：cargo test+clippy+gosec 等效工具）。

请参阅多语言工具链参考，了解各语言的测试 / lint / 安全 / 性能工具清单。

---

高级功能

质量门禁配置

三种严格度模式：

• 严格：所有 TRUST 维度均 ≥ 阈值，关键问题为零，覆盖率完整
• 标准：平均分 ≥ 阈值，没有关键问题阻止流程，允许警告
• 宽松：只有关键阻塞项会阻止流程继续

门禁配置：按维度设置阈值、按严重性设置问题上限、覆盖率目标、性能基准。

CI/CD 集成

四阶段流水线：代码质量 → 测试 → 性能 → 安全。任何阶段失败都会终止流水线，并生成该阶段专属的失败报告。

请参阅 CI/CD 集成模式（GitHub Actions + Docker），了解作业配置流程。

E2E / 浏览器测试

Playwright 模式（页面对象模型、跨浏览器、视觉回归）和文档查询集成。请参阅 Playwright 最佳实践。

---

模块

深入介绍各工作流阶段的模块。这里描述的是概念性工作流 （并非可导入的 SDK）——请使用项目自身的工具链来应用。请从 模块索引开始，或直接查看某个阶段：

• AI 驱动的调试 — 错误分类 + 解决方案候选项
• 智能重构 — 技术债分析 + 安全转换
• 性能优化 — 性能分析 + 瓶颈检测
• 自动化代码审查 — TRUST 5 评分 + 静态分析

---

配合使用效果良好

• moai-domain-backend：后端测试模式
• moai-domain-frontend：前端 UI 测试
• moai-foundation-core：SPEC 系统集成
• moai-domain-database / moai-domain-frontend / moai-domain-backend：特定平台的测试
• moai-workflow-project：项目管理工作流

---

状态：生产就绪 维护者：MoAI-ADK Development Workflow Team 版本：2.5.0（审计整改：语言中立性 + 重新关联模块）

常见借口

借口	实情
“这段代码已经有集成测试覆盖了”	集成测试发现的漏洞与单元测试不同。测试金字塔的存在自有道理。
“模拟数据库太难了，我就跳过这个测试”	如果测试因为耦合而难以编写，说明代码需要更好的抽象边界。
“80% 的覆盖率就够了”	覆盖率目标是底线，不是上限。缺失的 20% 往往包含错误处理路径。
“这些只是实用函数，不需要测试”	实用函数是复用最多的代码。实用函数中的漏洞会传播到各处。
“我在本地运行了测试，CI 肯定会通过”	环境差异会导致只在 CI 中出现的故障。相信 CI 输出，而不是本地运行结果。
“不稳定的测试很正常，重跑一下就行”	不稳定的测试会掩盖真实故障。修复不稳定问题，或明确将该测试隔离。

左移：尽早发现并修复缺陷。每个在 CI 中而非本地运行的测试都会增加延迟。每个本可作为单元测试、却写成 E2E 测试的测试都会增加脆弱性。

碧昂丝规则：如果你喜欢它，就应该给它写个测试。未经测试的行为，就是未定义的行为。

危险信号

• 新增功能后，覆盖率报告显示覆盖率下降
• 测试文件包含 t.Skip() 或 skip，但没有附带问题跟踪链接
• 测试名称是自动生成的（test_1、test_2），而不是描述行为的名称
• 没有测试覆盖新函数的错误／失败分支
• 测试文件导入了具体实现，而不是接口

验证

• 测试套件通过，且失败数为零（粘贴命令输出）
• 已生成覆盖率报告，变更涉及的包达到 85% 的门槛
• 错误路径有专门的测试用例（不只是成功路径）
• 没有引入不稳定的测试（使用 -count=3 运行以验证稳定性）
• 已确认测试相互隔离：每个测试都使用自己的测试夹具或 t.TempDir()
• 并发代码通过竞态检测器（go test -race 或等效工具）