前端低代码工作流自动化流程编排【免费下载链接】flowgram.aiFlowGram is an extensible workflow development framework with built-in canvas, form, variable, and materials that helps developers build AI workflow platforms faster and simpler.项目地址https://gitcode.com/gh_mirrors/fl/flowgram.ai点击查看免费下载FlowGram 是一个可扩展的工作流开发框架内置画布Canvas、表单Form、变量Variable与物料Materials能力其代码库以 Rush 管理的 pnpm monorepo 形式组织覆盖canvas-engine、node-engine、variable-engine、runtime、plugins、client等多个层次的包。本文以仓库内.claude/commands/add-tests.mdClaude Code 的/add-tests命令定义为骨架系统讲解 FlowGram 项目单元测试的生成流程、覆盖率分层目标、测试文件组织规范并结合真实源码与配置验证每一个环节。读完本文你将掌握如何为 FlowGram 任意包增量补测、为存量代码补齐覆盖率以及如何在仓库的 Vitest 与 Rush 体系下运行和验收测试。命令概览/add-tests能做什么/add-tests是 FlowGram 仓库为 Claude Code 定义的斜杠命令见 .claude/commands/add-tests.md用于自动生成和补充单元测试确保代码质量。命令的完整用法如下/add-tests [dir][dir]为可选参数可以是包名以开头、文件路径或目录路径不指定[dir]时默认面向全代码库操作但会先提示用户确认全代码库工作量巨大必须明确确认执行后会询问用户选择测试模式增量代码测试基于git diff或存量代码测试补齐。FlowGram 使用Vitest作为测试框架。这一点在仓库配置中有充分佐证例如 packages/canvas-engine/core/package.json 的devDependencies中声明了vitest: ^3.2.4与vitest/coverage-v8: ^3.2.4并定义了testvitest run与test:covvitest run --coverage脚本。覆盖率目标按包分类分层设定根据包的类型和重要性FlowGram 对不同层级设定了差异化的覆盖率目标层级包含目录覆盖率目标代表包核心引擎层packages/canvas-engine/、packages/node-engine/、packages/variable-engine/、packages/runtime/≥ 85%flowgram.ai/core、flowgram.ai/form、flowgram.ai/variable-core、flowgram.ai/runtime-js插件和客户端层packages/plugins/、packages/client/≥ 60%flowgram.ai/editor、各类 plugin 包、flowgram.ai/fixed-layout-editor工具和示例packages/common/、apps/尽可能覆盖关键逻辑flowgram.ai/utils、demo 应用该分层与仓库的 Rush 项目清单rush.json相互印证每个包通过packageName与projectFolder被登记在projects数组中如flowgram.ai/core对应packages/canvas-engine/core。生成测试时可从最近的package.json获取包名再以包名在rush.json中定位包的projectFolder从而确定其所属层级与覆盖率目标。测试文件组织规范测试文件位置优先放在与源码目录结构对应的__tests__/目录也可放在源文件同级的*.test.ts/*.test.tsx文件中命名规范对于src/core/utils.ts测试文件应为__tests__/core/utils.test.ts或src/core/utils.test.ts。仓库实际的组织方式完全遵循这一规范。以 packages/canvas-engine/core/tests为例__tests__/core/layer/config/editor-state-config-entity.spec.ts与src/core目录结构一一对应__tests__/services/clipboard-service.spec.ts、__tests__/services/storage-service.spec.ts按 service 模块组织__tests__/__snapshots__/存放快照测试产物如pipeline.spec.tsx.snap。同时Vitest 的匹配规则在 packages/canvas-engine/core/vitest.config.ts 中被显式配置为include: [**/?(*.){test,spec}.?(c|m)[jt]s?(x)]即test/spec后缀的.ts/.tsx文件都会被自动收集且默认排除__mocks__、dist、lib、cypress以及各类配置文件vitest.config.*等。测试生成流程详解第 0 步命令执行与用户确认确认范围若未指定[dir]询问用户是处理全代码库还是指定具体目录。全代码库操作工作量巨大需要用户明确确认选择模式询问用户选择测试模式增量代码测试仅为git diff中的新增/修改代码添加测试存量代码测试补齐扫描所有代码补齐缺失或覆盖率不足的测试。第 1 步识别待测代码增量代码模式下基于 git 状态定位变更# 检查 git diff 获取所有修改的文件 git diff --name-only git diff file # 查看具体变更存量代码模式下扫描指定目录下所有源文件排除已有完整测试的文件查找缺少测试或覆盖率不足的文件并优先处理核心引擎层的文件。第 2 步确定包信息和覆盖率目标从最近的package.json获取包名使用包名在rush.json中查找包的分类projectFolder根据包所在目录确定覆盖率目标packages/canvas-engine/、packages/node-engine/、packages/variable-engine/、packages/runtime/→ 85%packages/plugins/、packages/client/→ 60%packages/common/、apps/→ 尽可能覆盖。第 3 步生成测试代码测试重点包括新增或修改的函数、方法、类分支逻辑if/else、switch/case边界条件和异常处理依赖注入容器inversify的模拟响应式状态ReactiveState的行为验证。Vitest 最佳实践模板import { describe, it, expect, vi, beforeEach, afterEach } from vitest; import { render, screen } from testing-library/react; describe(ModuleName, () { beforeEach(() { // 初始化 }); it(should handle specific case, () { // 测试逻辑 expect(result).toBe(expected); }); });React 组件测试使用testing-library/react进行组件测试为关键元素添加data-testid属性测试用户交互和状态变化。依赖注入测试使用vi.mock()模拟依赖创建测试容器来验证服务注册。第 4 步执行测试验证单包测试cd packages/canvas-engine/core rushx test # 运行测试 rushx test:cov # 生成覆盖率报告全局测试rush test # 运行所有包的测试 rush test:cov # 生成所有包的覆盖率报告每次添加测试后立即运行测试确保通过 → 检查覆盖率是否达到目标 → 修复失败的测试或调整测试用例 → 继续处理下一个文件。第 5 步输出测试文件将测试文件保存到__tests__/目录优先或源文件同级保持目录结构与源代码一致添加必要的导入和类型声明。源码级测试实践从仓库真实用例看测试写法依赖注入inversify容器测试FlowGram 的核心引擎基于 inversify 的 IoC 容器。测试 packages/canvas-engine/core/tests/plugin.test.ts 展示了标准的容器测试模式import { interfaces, ContainerModule } from inversify; import { createPlaygroundPlugin, definePluginCreator, Playground, createPlaygroundContainer, PluginContext, loadPlugins, createPluginContextDefault, } from ../src; describe(playground plugin, () { let container: interfaces.Container; let playground: Playground; beforeEach(() { container createPlaygroundContainer(); playground container.getPlayground(Playground); }); it(createPlaygroundPlugin, () { const customPlugin createPlaygroundPlugin({ onBind({ bind }) { bind(customModel1).toConstantValue(customModel1); }, onInit(ctx) { isInit true; }, onReady(ctx) { isReady true; }, onDispose(ctx) { isDispose true; }, }); loadPlugins([customPlugin], container); expect(getPluginContext().playground).toEqual(playground); playground.init(); expect(isInit).toEqual(true); playground.ready(); expect(isReady).toEqual(true); playground.dispose(); expect(isDispose).toEqual(true); }); });该用例验证了插件生命周期钩子onBind/onInit/onReady/onDispose在容器中的正确触发顺序这正是「创建测试容器来验证服务注册」的落地示范。外部依赖 Mock测试 packages/canvas-engine/core/tests/utils.test.ts 展示了如何用vi.mock()屏蔽外部手势库vi.mock(use-gesture/vanilla, () { class MockGesture { config: any; constructor(target: HTMLElement, config: Config, pinchConfig: PinchConfig) { this.config { target, config, pinchConfig }; config.onPinch({ origin: [1, 2], first: true, last: true, movement: [], offset: [1, 2] }); pinchConfig.pinch.scaleBounds(); pinchConfig.pinch.from(); } } return { Gesture: MockGesture }; });随后构造PlaygroundDrag并断言start/stop后的状态如playgroundDrag.isStarted false完成对画布拖拽逻辑的隔离测试。可见 FlowGram 的 Mock 策略是外部依赖网络请求、文件系统、第三方手势库必须 mock内部复杂模块视情况 mock简单工具函数直接使用。React 组件与>data-testidsdk.flowcanvas.line.adder该data-testid在快照产物如packages/canvas-engine/renderer/__tests__/layers/__snapshots__/flow-label-layer.test.tsx.snap中反复出现说明组件测试通过该标识稳定断言渲染结果避免依赖易变的选择器。环境配置要点packages/canvas-engine/core/vitest.config.ts 中还有两个关键配置globals: true测试文件中可直接使用describe/it/expect等全局 API无需显式 importsetupFiles: [vitest.setup.ts]加载 packages/canvas-engine/core/vitest.setup.ts其内容为import reflect-metadata——这是 inversify 容器在测试环境正常工作的前提environment: jsdom为 React 组件测试提供 DOM 环境coverage.exclude中排除**/use-gesture/**说明该目录为第三方手势实现不计入覆盖率。示例命令与典型使用场景命令速查# 为某个包添加测试执行后会询问增量或存量 /add_tests flowgram.ai/core # 为特定目录添加测试 /add_tests packages/node-engine/form # 为单个文件添加测试 /add_tests packages/canvas-engine/core/src/core/utils.ts # 全代码库测试会先确认范围再询问增量或存量 /add_tests场景 1为新功能添加测试/add_tests packages/plugins/my-new-plugin # 选择增量代码测试 # 结果仅为 git diff 中的新代码生成测试适用于刚开发完一个插件只对本次改动生成测试避免触碰无关存量代码。场景 2提升现有包的测试覆盖率/add_tests flowgram.ai/variable-core # 选择存量代码测试补齐 # 结果扫描所有代码补齐缺失的测试目标 85% 覆盖率flowgram.ai/variable-core是变量引擎核心包见 packages/variable-engine/variable-core/package.json属于核心引擎层按分层目标应达到 ≥ 85% 覆盖率。场景 3全面测试检查/add_tests # 确认选择要处理的目录或全代码库 # 选择存量代码测试补齐 # 结果系统性地补齐整个项目的测试适用于发布前或大版本重构后的整体质量盘点。注意事项与最佳实践优先级优先为核心引擎层包编写高质量测试——引擎层覆盖率目标最高85%且是上层插件与客户端依赖的地基隔离性每个测试应该独立不依赖其他测试的执行顺序vitest.config.ts中的mockReset: false意味着 mock 不会自动重置因此需要测试间自行管理状态保证隔离可读性测试用例命名应清晰描述测试场景使用中文或英文皆可如should handle specific caseMock 策略外部依赖网络请求、文件系统必须 mock内部复杂模块可以考虑 mock简单工具函数可以直接使用快照测试谨慎使用快照测试仅用于稳定的 UI 或数据结构仓库中的__snapshots__/*.snap即用于稳定的画布渲染结构异步测试使用 async/await 处理异步操作确保 Promise 正确解决。工作流程总结完整的测试生成工作流如下接收命令用户执行/add_tests [dir]确认范围如果未指定dir询问用户要处理全代码库还是指定目录选择模式询问用户选择增量代码测试或存量代码测试补齐分析代码根据选择的模式识别待测代码增量模式基于git diff --name-only确定目标根据包的分类rush.json中的projectFolder确定覆盖率目标85% / 60% / 尽可能覆盖生成测试逐文件生成测试用例覆盖新增函数、分支逻辑、边界条件、inversify 容器与 ReactiveState 行为运行验证每生成一批测试后立即运行rushx test验证修复问题修复失败的测试或调整测试用例检查覆盖率运行rushx test:cov查看覆盖率报告是否达标继续迭代直到达到目标覆盖率或所有文件都有测试。对于 FlowGram 这类多层 monorepo引擎层、插件层、客户端层、工具与示例层并存的项目这套「按层定目标、按 diff 定增量、按容器定写法」的测试生成方法论既能守住核心引擎的质量红线又能避免在低价值工具代码上过度投入。开发者可以按本文流程结合 packages/canvas-engine/core/tests等真实测试目录对照学习逐步为 FlowGram 的每个包建立可验证、可度量的测试资产。赞分享前端低代码工作流自动化流程编排【免费下载链接】flowgram.aiFlowGram is an extensible workflow development framework with built-in canvas, form, variable, and materials that helps developers build AI workflow platforms faster and simpler.项目地址https://gitcode.com/gh_mirrors/fl/flowgram.ai点击查看免费下载相关推荐GSD「add-tests」命令实战为已完成阶段自动生成并提交单元测试与 E2E 测试GSD「add tests」命令实战为已完成阶段自动生成并提交单元测试与 E2E 测试 导读 /gsd:add tests 是 get shit doneG人工智能AI 应用提示工程开发工具工作流自动化AI AgentNango Monorepo 测试实战指南Vitest 单元测试、集成测试与 CLI 测试全解析Nango Monorepo 测试实战指南Vitest 单元测试、集成测试与 CLI 测试全解析 本篇指南以 .agents/skills/running t后端API网关AI 应用Agentic Awesome Skills 实战使用 Application Insights JavaScript SDK 为浏览器应用构建 TypeScript 前端可观测性Agentic Awesome Skills 实战使用 Application Insights JavaScript SDK 为浏览器应用构建 TypeScAI 技能AI 插件上一篇无需编程也能自动化浏览器Automa的PWA特性与插件功能完美融合下一篇2025最强数字电路学习指南从逻辑门到芯片设计的视频课程精选创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考