claude-task-master 配置驱动 Mock 系统实战用 Mock 工厂重构跨标签任务测试【免费下载链接】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 仓库中move-cross-tag.test.js重构沉淀下来的一套配置驱动configuration-drivenMock 系统它以一份mockConfig配置对象声明测试所需的依赖通过createMockFactory()与setupMocks()两个函数按需生成并挂载 Jest mock将原先 20 模块、150 行的脆弱 mock 代码压缩到约 50 行。读完本文你将掌握这套 mock 工厂的完整设计配置结构、工厂函数、可选 mock 分层、三种典型用法默认 / 最小 / 选择性配置、迁移到其他测试文件的方法以及它背后真实被测函数moveTasksBetweenTagsscripts/modules/task-manager/move-task.js的调用链与校验逻辑。背景为什么要重构这套 Mock在 tests/unit/scripts/modules/commands/move-cross-tag.test.js 中CLI 的跨标签移动任务功能task-master move --from --from-tag --to-tag需要被隔离测试。原实现存在三个典型问题过度 Mock一次性 mock 了 20 个模块其中大量模块与跨标签移动功能毫无关系既增加测试启动开销也让失败定位变得困难重复代码每个用例都要手写jest.mock()调用mock 的创建、命名、返回值设置散落各处维护成本高隐含依赖没有显式声明这个测试到底依赖哪些模块能力新读者难以从测试代码中快速辨认依赖边界。重构后的 Mock 系统以只 mock 实际使用的东西为原则把依赖声明收敛到一份配置对象中测试的意图一目了然。核心设计文档见 tests/unit/scripts/modules/commands/README.md本文以下内容均以该文档为骨架展开并辅以源码佐证。Mock 系统的三大设计支柱1. 聚焦式 MockFocused Mocking重构前后对比BeforeMock 了 20 个模块很多与跨标签功能无关After只 mock 5 个核心模块——它们恰好是moveTasksBetweenTags真实调用链上必需的依赖。从真实实现看这 5 个模块的对应关系可以精确落到源码Mock 名真实来源在调用链中的职责moveTasksBetweenTagsscripts/modules/task-manager/move-task.js跨标签移动的核心执行函数校验 → 准备数据 → 解析依赖 → 执行 → 落盘readJSONscripts/modules/utils.js读取某 tag 下的任务数据readJSON(filepath, projectRoot, tag)initTaskMasterscripts/modules/config-manager.js初始化 TaskMaster 实例提供getTasksPath/getProjectRoot/getCurrentTagfindProjectRootscripts/modules/utils.js解析项目根目录用于 tag 感知路径解析generateTaskFiles移动后重新生成任务文件的逻辑保证移动结果与文件系统一致说明README 中的generateTaskFiles对应的是移动后文件再生成这一动作。当前版本源码中该职责由writeJSONscripts/modules/utils.js在finalizeMove阶段承担move-task.js测试中通过配置开关控制是否需要该 mock。2. 配置驱动的 MockConfiguration-Driven Mocking整个系统的心脏是一份配置对象它用布尔值声明本次测试需要哪些 mockconst mockConfig { core: { moveTasksBetweenTags: true, generateTaskFiles: true, readJSON: true, initTaskMaster: true, findProjectRoot: true } };实际测试文件中这份配置被扩展为三层结构move-cross-tag.test.js语义更完整const mockConfig { // Core functionality mocks (always needed) core: { moveTasksBetweenTags: true, readJSON: true, initTaskMaster: true, findProjectRoot: true }, // Console and process mocks console: { error: true, log: true, exit: true }, // TaskMaster instance mocks taskMaster: { getCurrentTag: true, getTasksPath: true, getProjectRoot: true } };配置即文档core层声明真实业务依赖console层声明输出与进程退出taskMaster层声明 TaskMaster 实例上的方法。测试维护者无需阅读大量jest.mock代码只看配置就能知道被测对象的外部边界。3. 可复用 Mock 工厂Reusable Mock Factory工厂函数读取配置、按需创建带名字的 mock 函数function createMock(name) { return jest.fn().mockName(name); } function createMockFactory(config mockConfig) { const mocks {}; if (config.core?.moveTasksBetweenTags) { mocks.moveTasksBetweenTags createMock(moveTasksBetweenTags); } if (config.core?.readJSON) { mocks.readJSON createMock(readJSON); } if (config.core?.initTaskMaster) { mocks.initTaskMaster createMock(initTaskMaster); } if (config.core?.findProjectRoot) { mocks.findProjectRoot createMock(findProjectRoot); } return mocks; }createMock(name)统一使用jest.fn().mockName(name)命名保证断言失败时 Jest 输出的调用信息可读createMockFactory使用可选链config.core?.xxx即使传入残缺配置也不会抛错。setupMocks()则在工厂之上完成真正的jest.mock()挂载move-cross-tag.test.js例如按配置替换真实模块function setupMocks(config mockConfig) { const mocks createMockFactory(config); if (config.core?.moveTasksBetweenTags) { jest.mock( ../../../../../scripts/modules/task-manager/move-task.js, () ({ moveTasksBetweenTags: mocks.moveTasksBetweenTags }) ); } if (config.core?.readJSON || config.core?.findProjectRoot) { jest.mock(../../../../../scripts/modules/utils.js, () ({ findProjectRoot: mocks.findProjectRoot, readJSON: mocks.readJSON, log: jest.fn(), writeJSON: jest.fn(), getCurrentTag: jest.fn(() master) })); } if (config.core?.initTaskMaster) { jest.mock(../../../../../scripts/modules/config-manager.js, () ({ initTaskMaster: mocks.initTaskMaster, isApiKeySet: jest.fn(() true), getConfig: jest.fn(() ({})) })); } // chalk 统一透传保证输出断言稳定 jest.mock(chalk, () ({ red: jest.fn((text) text), blue: jest.fn((text) text), green: jest.fn((text) text), yellow: jest.fn((text) text), white: jest.fn((text) ({ bold: jest.fn((text) text) })), reset: jest.fn((text) text) })); return mocks; }注意utils.js的 mock 中保留了getCurrentTag: jest.fn(() master)与writeJSON等可能被用到的最小集合这与 README 中只 mock 实际使用的东西并不矛盾——它只 mock 该模块被调用到的少数导出而非整个模块的全部能力。可选 Mock 的分层README 将 mock 划分为两组核心 Mock跨标签功能必需moveTasksBetweenTags核心移动功能generateTaskFiles移动后的文件生成readJSON读取任务数据initTaskMasterTaskMaster 初始化findProjectRoot项目路径解析。可选 Mock控制台方法error、log、exit——用于断言错误输出与进程退出行为对应console与process.exit的jest.spyOn场景TaskMaster 实例方法getCurrentTag、getTasksPath、getProjectRoot——用于构造被测函数所需的taskMaster上下文。在测试的beforeEach中这些可选 mock 通过jest.spyOn建立并为initTaskMaster、findProjectRoot、readJSON预设返回值为后续用例服务move-cross-tag.test.jsmockTaskMaster { getCurrentTag: jest.fn().mockReturnValue(master), getTasksPath: jest.fn().mockReturnValue(/test/path/tasks.json), getProjectRoot: jest.fn().mockReturnValue(/test/project) }; mocks.initTaskMaster.mockReturnValue(mockTaskMaster); mocks.findProjectRoot.mockReturnValue(/test/project); mocks.readJSON.mockReturnValue({ tasks: [ { id: 1, title: Test Task 1 }, { id: 2, title: Test Task 2 } ] });三种用法示例默认配置不传参即使用完整mockConfig适用于大多数用例const mocks setupMocks(); // Uses default mockConfig最小配置只声明被测路径真正触及的依赖适合验证最简依赖下也能工作const minimalConfig { core: { moveTasksBetweenTags: true, generateTaskFiles: true, readJSON: true } }; const mocks setupMocks(minimalConfig);选择性 Mock按需禁用显式把某个依赖置为false验证禁用后该 mock 不被创建、相关行为不受影响const selectiveConfig { core: { moveTasksBetweenTags: true, generateTaskFiles: false, // Disabled readJSON: true } }; const mocks setupMocks(selectiveConfig);对应的测试断言move-cross-tag.test.jsit(should work with minimal mock configuration, () { const minimalMocks createMockFactory(minimalConfig); expect(minimalMocks.moveTasksBetweenTags).toBeDefined(); expect(minimalMocks.readJSON).toBeDefined(); }); it(should allow disabling specific mocks, () { const selectiveMocks createMockFactory(selectiveConfig); expect(selectiveMocks.moveTasksBetweenTags).toBeDefined(); expect(selectiveMocks.readJSON).toBeUndefined(); // 已禁用 });收益为什么这套设计值得推广复杂度下降mock 装配代码从 150 行降到约 50 行测试文件主体回归测什么而非怎么搭可维护性提升配置对象显式呈现依赖关系新增/删除依赖只需改一行布尔值测试聚焦只 mock 实际使用的模块减少无关 mock 带来的误报与噪音配置灵活任意开关组合天然支持最小配置禁用某依赖等边界场景命名一致所有 mock 统一走createMock()并带描述性名称Jest 失败信息友好。迁移指南将这套模式复制到其他测试文件README 给出的迁移步骤结合本项目实际模块可操作如下识别真实模块依赖打开被测模块的import语句例如 move-task.js 顶部导入的dependency-manager.jsfindCrossTagDependencies、getDependentTaskIds、validateSubtaskMove与utils.jslog、readJSON、setTasksForTag、traverseDependencies、writeJSON只保留被测代码真正调用的导出为必需 mock 创建配置对象仿照mockConfig组织core/console/taskMaster分层接入createMockFactory()与setupMocks()工厂负责创建、setupMocks负责jest.mock挂载两者分离便于单独对工厂做单元验证移除多余 mock对照依赖清单删除所有未使用的jest.mock()调用。迁移前后对比// Before: 20 jest.mock() calls jest.mock(module1, () ({ ... })); jest.mock(module2, () ({ ... })); // ... many more // After: Configuration-driven const mockConfig { core: { requiredFunction1: true, requiredFunction2: true } }; const mocks setupMocks(mockConfig);被 Mock 包裹的真实逻辑跨标签移动调用链理解 mock 系统的意义离不开它服务的真实功能。handleCrossTagMovescripts/modules/commands.js是 CLI 层入口校验--from必填、拆分逗号分隔的任务 ID、构造moveOptions随后调用被 mock 的moveTasksBetweenTagsconst sourceIds sourceId.split(,).map((id) id.trim()); const moveOptions { withDependencies: options.withDependencies || false, ignoreDependencies: options.ignoreDependencies || false }; const result await moveTasksBetweenTags( taskMaster.getTasksPath(), sourceIds, sourceTag, toTag, moveOptions, { projectRoot: taskMaster.getProjectRoot() } );真实实现move-task.js分为五阶段校验validateMove含跨标签依赖冲突检查加载数据prepareTaskData得到rawData、sourceTasks、allTasks解析依赖resolveDependencies依据withDependencies/ignoreDependencies决定联动移动还是切断跨标签依赖执行移动executeMoveOperation移动任务并维护tag属性与metadata.moveHistory见preserveTaskMetadatamove-task.js落盘返回finalizeMove调用writeJSON保存若曾忽略依赖则附带validate-dependencies/fix-dependencies建议move-task.js。错误码集中在MOVE_ERROR_CODESmove-task.js其中SOURCE_TARGET_TAGS_SAME、CROSS_TAG_DEPENDENCY_CONFLICTS等正是测试用例覆盖的边界。测试套件move-cross-tag.test.js围绕该调用链验证了基础跨标签移动、--with-dependencies/--ignore-dependencies透传、缺--from报错、源/目标 tag 相同报错、未提供--from-tag时回退当前 tag、逗号分隔多任务移动与空格容错等场景。小结这套配置驱动的 Mock 系统是先声明依赖、再按需装配思想的落地配置对象让依赖一目了然工厂函数统一了 mock 的创建与命名setupMocks收敛了jest.mock的样板代码。它不仅让 move-cross-tag.test.js 变得可维护也为仓库中其他测试文件提供了一条低成本的迁移路径——你可以在 tests/unit/scripts/modules 下看到同类测试如dependency-manager/的跨标签依赖测试、task-manager/move-task.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），仅供参考
claude-task-master 配置驱动 Mock 系统实战：用 Mock 工厂重构跨标签任务测试
claude-task-master 配置驱动 Mock 系统实战用 Mock 工厂重构跨标签任务测试【免费下载链接】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 仓库中move-cross-tag.test.js重构沉淀下来的一套配置驱动configuration-drivenMock 系统它以一份mockConfig配置对象声明测试所需的依赖通过createMockFactory()与setupMocks()两个函数按需生成并挂载 Jest mock将原先 20 模块、150 行的脆弱 mock 代码压缩到约 50 行。读完本文你将掌握这套 mock 工厂的完整设计配置结构、工厂函数、可选 mock 分层、三种典型用法默认 / 最小 / 选择性配置、迁移到其他测试文件的方法以及它背后真实被测函数moveTasksBetweenTagsscripts/modules/task-manager/move-task.js的调用链与校验逻辑。背景为什么要重构这套 Mock在 tests/unit/scripts/modules/commands/move-cross-tag.test.js 中CLI 的跨标签移动任务功能task-master move --from --from-tag --to-tag需要被隔离测试。原实现存在三个典型问题过度 Mock一次性 mock 了 20 个模块其中大量模块与跨标签移动功能毫无关系既增加测试启动开销也让失败定位变得困难重复代码每个用例都要手写jest.mock()调用mock 的创建、命名、返回值设置散落各处维护成本高隐含依赖没有显式声明这个测试到底依赖哪些模块能力新读者难以从测试代码中快速辨认依赖边界。重构后的 Mock 系统以只 mock 实际使用的东西为原则把依赖声明收敛到一份配置对象中测试的意图一目了然。核心设计文档见 tests/unit/scripts/modules/commands/README.md本文以下内容均以该文档为骨架展开并辅以源码佐证。Mock 系统的三大设计支柱1. 聚焦式 MockFocused Mocking重构前后对比BeforeMock 了 20 个模块很多与跨标签功能无关After只 mock 5 个核心模块——它们恰好是moveTasksBetweenTags真实调用链上必需的依赖。从真实实现看这 5 个模块的对应关系可以精确落到源码Mock 名真实来源在调用链中的职责moveTasksBetweenTagsscripts/modules/task-manager/move-task.js跨标签移动的核心执行函数校验 → 准备数据 → 解析依赖 → 执行 → 落盘readJSONscripts/modules/utils.js读取某 tag 下的任务数据readJSON(filepath, projectRoot, tag)initTaskMasterscripts/modules/config-manager.js初始化 TaskMaster 实例提供getTasksPath/getProjectRoot/getCurrentTagfindProjectRootscripts/modules/utils.js解析项目根目录用于 tag 感知路径解析generateTaskFiles移动后重新生成任务文件的逻辑保证移动结果与文件系统一致说明README 中的generateTaskFiles对应的是移动后文件再生成这一动作。当前版本源码中该职责由writeJSONscripts/modules/utils.js在finalizeMove阶段承担move-task.js测试中通过配置开关控制是否需要该 mock。2. 配置驱动的 MockConfiguration-Driven Mocking整个系统的心脏是一份配置对象它用布尔值声明本次测试需要哪些 mockconst mockConfig { core: { moveTasksBetweenTags: true, generateTaskFiles: true, readJSON: true, initTaskMaster: true, findProjectRoot: true } };实际测试文件中这份配置被扩展为三层结构move-cross-tag.test.js语义更完整const mockConfig { // Core functionality mocks (always needed) core: { moveTasksBetweenTags: true, readJSON: true, initTaskMaster: true, findProjectRoot: true }, // Console and process mocks console: { error: true, log: true, exit: true }, // TaskMaster instance mocks taskMaster: { getCurrentTag: true, getTasksPath: true, getProjectRoot: true } };配置即文档core层声明真实业务依赖console层声明输出与进程退出taskMaster层声明 TaskMaster 实例上的方法。测试维护者无需阅读大量jest.mock代码只看配置就能知道被测对象的外部边界。3. 可复用 Mock 工厂Reusable Mock Factory工厂函数读取配置、按需创建带名字的 mock 函数function createMock(name) { return jest.fn().mockName(name); } function createMockFactory(config mockConfig) { const mocks {}; if (config.core?.moveTasksBetweenTags) { mocks.moveTasksBetweenTags createMock(moveTasksBetweenTags); } if (config.core?.readJSON) { mocks.readJSON createMock(readJSON); } if (config.core?.initTaskMaster) { mocks.initTaskMaster createMock(initTaskMaster); } if (config.core?.findProjectRoot) { mocks.findProjectRoot createMock(findProjectRoot); } return mocks; }createMock(name)统一使用jest.fn().mockName(name)命名保证断言失败时 Jest 输出的调用信息可读createMockFactory使用可选链config.core?.xxx即使传入残缺配置也不会抛错。setupMocks()则在工厂之上完成真正的jest.mock()挂载move-cross-tag.test.js例如按配置替换真实模块function setupMocks(config mockConfig) { const mocks createMockFactory(config); if (config.core?.moveTasksBetweenTags) { jest.mock( ../../../../../scripts/modules/task-manager/move-task.js, () ({ moveTasksBetweenTags: mocks.moveTasksBetweenTags }) ); } if (config.core?.readJSON || config.core?.findProjectRoot) { jest.mock(../../../../../scripts/modules/utils.js, () ({ findProjectRoot: mocks.findProjectRoot, readJSON: mocks.readJSON, log: jest.fn(), writeJSON: jest.fn(), getCurrentTag: jest.fn(() master) })); } if (config.core?.initTaskMaster) { jest.mock(../../../../../scripts/modules/config-manager.js, () ({ initTaskMaster: mocks.initTaskMaster, isApiKeySet: jest.fn(() true), getConfig: jest.fn(() ({})) })); } // chalk 统一透传保证输出断言稳定 jest.mock(chalk, () ({ red: jest.fn((text) text), blue: jest.fn((text) text), green: jest.fn((text) text), yellow: jest.fn((text) text), white: jest.fn((text) ({ bold: jest.fn((text) text) })), reset: jest.fn((text) text) })); return mocks; }注意utils.js的 mock 中保留了getCurrentTag: jest.fn(() master)与writeJSON等可能被用到的最小集合这与 README 中只 mock 实际使用的东西并不矛盾——它只 mock 该模块被调用到的少数导出而非整个模块的全部能力。可选 Mock 的分层README 将 mock 划分为两组核心 Mock跨标签功能必需moveTasksBetweenTags核心移动功能generateTaskFiles移动后的文件生成readJSON读取任务数据initTaskMasterTaskMaster 初始化findProjectRoot项目路径解析。可选 Mock控制台方法error、log、exit——用于断言错误输出与进程退出行为对应console与process.exit的jest.spyOn场景TaskMaster 实例方法getCurrentTag、getTasksPath、getProjectRoot——用于构造被测函数所需的taskMaster上下文。在测试的beforeEach中这些可选 mock 通过jest.spyOn建立并为initTaskMaster、findProjectRoot、readJSON预设返回值为后续用例服务move-cross-tag.test.jsmockTaskMaster { getCurrentTag: jest.fn().mockReturnValue(master), getTasksPath: jest.fn().mockReturnValue(/test/path/tasks.json), getProjectRoot: jest.fn().mockReturnValue(/test/project) }; mocks.initTaskMaster.mockReturnValue(mockTaskMaster); mocks.findProjectRoot.mockReturnValue(/test/project); mocks.readJSON.mockReturnValue({ tasks: [ { id: 1, title: Test Task 1 }, { id: 2, title: Test Task 2 } ] });三种用法示例默认配置不传参即使用完整mockConfig适用于大多数用例const mocks setupMocks(); // Uses default mockConfig最小配置只声明被测路径真正触及的依赖适合验证最简依赖下也能工作const minimalConfig { core: { moveTasksBetweenTags: true, generateTaskFiles: true, readJSON: true } }; const mocks setupMocks(minimalConfig);选择性 Mock按需禁用显式把某个依赖置为false验证禁用后该 mock 不被创建、相关行为不受影响const selectiveConfig { core: { moveTasksBetweenTags: true, generateTaskFiles: false, // Disabled readJSON: true } }; const mocks setupMocks(selectiveConfig);对应的测试断言move-cross-tag.test.jsit(should work with minimal mock configuration, () { const minimalMocks createMockFactory(minimalConfig); expect(minimalMocks.moveTasksBetweenTags).toBeDefined(); expect(minimalMocks.readJSON).toBeDefined(); }); it(should allow disabling specific mocks, () { const selectiveMocks createMockFactory(selectiveConfig); expect(selectiveMocks.moveTasksBetweenTags).toBeDefined(); expect(selectiveMocks.readJSON).toBeUndefined(); // 已禁用 });收益为什么这套设计值得推广复杂度下降mock 装配代码从 150 行降到约 50 行测试文件主体回归测什么而非怎么搭可维护性提升配置对象显式呈现依赖关系新增/删除依赖只需改一行布尔值测试聚焦只 mock 实际使用的模块减少无关 mock 带来的误报与噪音配置灵活任意开关组合天然支持最小配置禁用某依赖等边界场景命名一致所有 mock 统一走createMock()并带描述性名称Jest 失败信息友好。迁移指南将这套模式复制到其他测试文件README 给出的迁移步骤结合本项目实际模块可操作如下识别真实模块依赖打开被测模块的import语句例如 move-task.js 顶部导入的dependency-manager.jsfindCrossTagDependencies、getDependentTaskIds、validateSubtaskMove与utils.jslog、readJSON、setTasksForTag、traverseDependencies、writeJSON只保留被测代码真正调用的导出为必需 mock 创建配置对象仿照mockConfig组织core/console/taskMaster分层接入createMockFactory()与setupMocks()工厂负责创建、setupMocks负责jest.mock挂载两者分离便于单独对工厂做单元验证移除多余 mock对照依赖清单删除所有未使用的jest.mock()调用。迁移前后对比// Before: 20 jest.mock() calls jest.mock(module1, () ({ ... })); jest.mock(module2, () ({ ... })); // ... many more // After: Configuration-driven const mockConfig { core: { requiredFunction1: true, requiredFunction2: true } }; const mocks setupMocks(mockConfig);被 Mock 包裹的真实逻辑跨标签移动调用链理解 mock 系统的意义离不开它服务的真实功能。handleCrossTagMovescripts/modules/commands.js是 CLI 层入口校验--from必填、拆分逗号分隔的任务 ID、构造moveOptions随后调用被 mock 的moveTasksBetweenTagsconst sourceIds sourceId.split(,).map((id) id.trim()); const moveOptions { withDependencies: options.withDependencies || false, ignoreDependencies: options.ignoreDependencies || false }; const result await moveTasksBetweenTags( taskMaster.getTasksPath(), sourceIds, sourceTag, toTag, moveOptions, { projectRoot: taskMaster.getProjectRoot() } );真实实现move-task.js分为五阶段校验validateMove含跨标签依赖冲突检查加载数据prepareTaskData得到rawData、sourceTasks、allTasks解析依赖resolveDependencies依据withDependencies/ignoreDependencies决定联动移动还是切断跨标签依赖执行移动executeMoveOperation移动任务并维护tag属性与metadata.moveHistory见preserveTaskMetadatamove-task.js落盘返回finalizeMove调用writeJSON保存若曾忽略依赖则附带validate-dependencies/fix-dependencies建议move-task.js。错误码集中在MOVE_ERROR_CODESmove-task.js其中SOURCE_TARGET_TAGS_SAME、CROSS_TAG_DEPENDENCY_CONFLICTS等正是测试用例覆盖的边界。测试套件move-cross-tag.test.js围绕该调用链验证了基础跨标签移动、--with-dependencies/--ignore-dependencies透传、缺--from报错、源/目标 tag 相同报错、未提供--from-tag时回退当前 tag、逗号分隔多任务移动与空格容错等场景。小结这套配置驱动的 Mock 系统是先声明依赖、再按需装配思想的落地配置对象让依赖一目了然工厂函数统一了 mock 的创建与命名setupMocks收敛了jest.mock的样板代码。它不仅让 move-cross-tag.test.js 变得可维护也为仓库中其他测试文件提供了一条低成本的迁移路径——你可以在 tests/unit/scripts/modules 下看到同类测试如dependency-manager/的跨标签依赖测试、task-manager/move-task.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），仅供参考
)
)
