claude-task-master 项目 Roo 集成测试指南：从自动化测试到手动验证与兼容性检查
claude-task-master 项目 Roo 集成测试指南从自动化测试到手动验证与兼容性检查【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master导读本文档面向希望验证 claude-task-master 中 Roo Coderoocode集成完整性的开发者与贡献者系统介绍 Roo 集成相关的自动化测试、手工打包安装验证以及与其他编辑器如 Cursor的兼容性检查流程。读完本文你将掌握如何在本地运行 Roo 集成测试、通过npm pack打包真实安装包并核对.roo目录与.roomodes文件的生成结果以及如何确保 Roo 与 Cursor 规则文件共存互不干扰。一、Roo 集成是什么一句话定位claude-task-master 是一个可嵌入 Cursor、Lovable、Windsurf、Roo 等 AI 编程环境的 AI 任务管理系统。Roo 集成指的是项目在初始化时task-master init自动生成 Roo Code 所需的规则文件体系包括项目根目录下的.roomodes文件与.roo目录从而让 Roo Code 编辑器能够按 Task Master 的规范运行多模式协作工作流。从源码结构看这套集成由三个关键部分构成源资产assets/roocode/.roomodes与assets/roocode/.roo模式规则源文件生成逻辑src/profiles/roo.js 中的 Roo 规则 Profile负责把源资产复制到目标项目并做 MCP 配置增强验证逻辑tests/integration/profiles/下的 Roo 相关测试文件。二、自动化测试三种运行方式2.1 运行全部测试npm test该命令执行项目完整的测试套件Roo 集成测试作为其中的一部分被一并执行。2.2 只运行 Roo 相关测试npm test -- -t Roo利用 Jest 的-t参数按测试名称过滤只执行名称中包含 Roo 的测试用例。2.3 运行指定测试文件npm test -- tests/integration/roo-files-inclusion.test.js直接指定单个测试文件路径适合在修改 Roo 相关源码后进行快速回归。2.4 测试到底验证了什么源码级解读tests/integration/profiles/roo-files-inclusion.test.js是本集成最核心的自动化验证它从三个层面确认 Roo 文件确实进入了最终发布包第一层发布清单package.json 的 files 数组测试断言package.json的files数组中包含dist/**见 package.json。这是因为构建产物被输出到dist目录——tsdown.config.ts 中配置了outDir: dist与copy: [assets]意味着assets目录含roocode子目录会在打包时被复制进dist从而随包发布。第二层roo.js Profile 的实现逻辑测试逐项断言 src/profiles/roo.js 中必须存在以下关键实现onAddRulesProfile(targetDir, assetsDir)主处理函数递归复制源目录的copyRecursiveSync(sourceDir, targetDir)基于path.join(assetsDir, roocode)的源路径解析而非硬编码相对路径.roomodes文件的源/目标路径逻辑path.join(sourceDir, .roomodes)与path.join(targetDir, .roomodes)按模式循环复制规则文件的for (const mode of ROO_MODES)及对应的rules-${mode}/${mode}-rules路径模板。第三层源资产存在性测试直接校验assets/roocode/.roo与assets/roocode/.roomodes两个源资产真实存在本仓库中确已存在.roomodes源文件内容定义了 orchestrator、architect、ask、debug、test 等自定义模式。此外tests/integration/profiles/roo-init-functionality.test.js还补充验证了roo.js使用工厂模式创建 Profile、使用ROO_STYLE工具映射、以及onAddRulesProfile能正确复制.roomodes与各模式规则文件。2.5 测试背后的模式清单与配置事实Roo 支持的模式定义在 src/constants/profiles.js 中集中维护export const ROO_MODES [ architect, ask, orchestrator, code, debug, test ];roo.js通过import { ROO_MODES } from ../constants/profiles.js引用该清单测试也专门断言了这一导入路径避免模式清单出现两处定义漂移。而 assets/roocode/.roomodes 中实际声明的customModes包含 orchestrator、architect、ask、debug、test 五种自定义模式其权限分组groups覆盖read、edit、browser、command、mcp等能力。另外roo.js在onPostConvertRulesProfile阶段会调用enhanceRooMCPConfiguration为.roo/mcp.json中task-master-ai服务器追加timeout: 300的超时配置以适配 Roo 长耗时 AI 操作。三、手动验证打包安装并检查文件落位自动化测试之外文档还提供了一套完全脱离测试框架的人工验证流程用于模拟真实用户通过 npm 安装包后的落地效果。3.1 创建测试目录并初始化 npm 项目mkdir test-tm cd test-tm3.2 生成 package.jsonnpm init -y3.3 本地打包并安装# 回到 claude-task-master 仓库根目录执行打包 cd .. npm pack # 打包完成后会在仓库根目录生成类似 task-master-ai-0.12.0.tgz 的压缩包 #具体版本号以仓库 package.json 中 version 字段为准 # 返回测试目录并从本地 tgz 安装 cd test-tm npm install ../task-master-ai-0.12.0.tgznpm pack会依据package.json的files字段含dist/**生成 tarball而dist目录内已由tsdown的copy: [assets]注入assets/roocode因此安装包中必然包含 Roo 源资产。3.4 初始化 Task Master 项目npx task-master init --yesinit命令会根据规则 Profile 配置触发roo.js的onAddRulesProfile回调先整体递归复制assets/roocode到目标目录再单独把.roomodes复制到项目根目录最后为每个模式把rules-${mode}/${mode}-rules复制到.roo/rules-${mode}/下。3.5 核对所有 Roo 文件与目录# 确认 .roomodes 文件存在于项目根目录 ls -la | grep .roomodes # 确认 .roo 目录及其全部模式子目录存在 ls -la .roo ls -la .roo/rules ls -la .roo/rules-architect ls -la .roo/rules-ask ls -la .roo/rules-orchestrator ls -la .roo/rules-code ls -la .roo/rules-debug ls -la .roo/rules-test注意上表中的模式子目录与ROO_MODES常量一一对应architect、ask、orchestrator、code、debug、test共六个模式目录。其中.roo/rules是onAddRulesProfile中copyRecursiveSync(sourceDir, targetDir)整体复制assets/roocode/.roo时带过来的通用规则目录。四、What to Look For验收核对清单无论跑测试还是手动验证都应按以下四项检查是否达标发布清单package.json的files数组包含dist/**从而确保assets/roocode含.roo/**与.roomodes随打包进入发布产物打包校验脚本prepare-package.js或等价构建步骤会校验所有必需 Roo 文件的存在性防止静默缺失初始化脚本init.js创建全部.roo目录并复制.roomodes文件实际由roo.js的onAddRulesProfile回调承担源资产Roo 集成的所有源文件存在于assets/roocode/.roo与assets/roocode/.roomodes。说明本仓库当前构建体系以 tsdown.config.ts 的copy: [assets]承担资产注入prepare-package.js的存在与否以发布分支实际脚本为准但从自动化测试的断言看其核心意图确保 Roo 文件进入最终包由dist/** 资产复制机制等价实现。五、兼容性验证Roo 与 Cursor 共存Roo 集成不能破坏既有 Cursor 功能因此文档专门给出了共存验证流程npx task-master init --yes初始化完成后依次检查.cursor与.roo两个目录同时存在.windsurfrules与.roomodes两个文件同时存在原有功能Cursor 规则、任务管理命令等继续按预期工作。从实现层面看这种共存是天然成立的每种编辑器对应独立的 Profile如cursorProfile 与rooProfile各自拥有独立的onAdd生命周期回调与目标路径.cursor目录 vs.roo目录互不覆盖。而且roo.js的onRemoveRulesProfile只清理.roomodes、.roo/mcp.json以及rules-*模式目录并在目录清空后才删除整个.roo目录删除逻辑同样是隔离的不会波及.cursor相关文件。六、常见问题与排查建议.roo/rules-*目录未生成优先检查assets/roocode/.roo/rules-*源资产是否存在、ROO_MODES中的模式名是否与源目录命名一致均为rules-{mode}/{mode}-rules。.roomodes未出现在项目根目录确认源文件assets/roocode/.roomodes存在且onAddRulesProfile的复制逻辑被执行可观察日志中的[Roo] Copied .roomodes to ...。打包后 Roo 文件丢失检查package.json的files数组是否包含dist/**以及tsdown.config.ts中copy是否包含assets。MCP 超时未生效确认.roo/mcp.json中task-master-ai服务器存在onPostConvertRulesProfile才会为其追加timeout: 300。七、相关阅读规则 Profile 的实现src/profiles/roo.jsonAddRulesProfile、onRemoveRulesProfile、onPostConvertRulesProfileRoo 模式常量定义src/constants/profiles.jsRoo 源资产assets/roocode/.roomodes发布文件清单package.json构建资产复制配置tsdown.config.ts集成测试tests/integration/profiles/roo-files-inclusion.test.js 与 tests/integration/profiles/roo-init-functionality.test.js【免费下载链接】claude-task-masterAn AI-powered task-management system you can drop into Cursor, Lovable, Windsurf, Roo, and others.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-task-master创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考