后端前端【免费下载链接】flagsmithFlagsmith is an open-source feature flag platform with remote config, experimentation, and self-hosted or cloud deployment options.项目地址https://gitcode.com/gh_mirrors/fl/flagsmith点击查看免费下载本指南围绕 Flagsmith 前端仓库中的测试生成工作流即 frontend/.claude/commands/unit-test.md 所定义的规范系统讲解如何为任一前端源文件生成高质量 Jest 单元测试。你将掌握从源文件可测试性分析、测试文件放置与路径别名到describeit.each表驱动测试结构、边界用例设计以及npm run test:unit执行与覆盖率反馈的完整闭环并借助仓库内真实测试范例获得可直接复用的编写模板。一、命令文档定位一套可复用的前端测试生成工作流frontend/.claude/commands/unit-test.md是 Flagsmith 前端仓库内为 AI 编码助手定义的一条命令分析指定的前端文件并为其生成 Jest 单元测试。它以$ARGUMENTS接收目标文件路径规定了一套从“检查既有测试”到“生成测试并运行验证”的五步流程。该命令的适用范围有明确边界仅针对前端代码TypeScript / React测试框架为Jest后端 PythonDjango测试不在其列相关说明位于 api/README.md。这意味着该工作流与前端目录的组织方式frontend/common、frontend/web深度绑定下一节将逐步拆解其每一步的技术细节。二、第一步检查现有测试定位覆盖缺口生成新测试之前第一步是探查目标文件是否已有测试在源文件同目录下寻找__tests__/{filename}.test.ts。Flagsmith 的 Jest 配置frontend/jest.config.js通过testMatch: [**/__tests__/**/*.test.ts, **/*.test.ts]认定了两类测试位置仓库中__tests__目录是主流约定。若测试已存在则分析其覆盖缺口coverage gaps而非盲目重复生成。以仓库现状为例frontend/common/utils/下存在一组与源文件一一对应的测试format.test.ts、featureFilterParams.test.ts、csv.test.ts、sanitizeFeatureName.test.ts、copyToClipboard.test.ts等 16 个文件均遵循common/utils/__tests__/的布局可作为判断“已有测试”的参照。三、第二步源文件分析与可测试性评估生成测试前命令要求先读懂源文件识别三个要素导出物所有导出的函数、类、常量依赖与导入文件引用了哪些模块services、store、其他 utils这些依赖是否会在测试中产生副作用可测试性分级类型可测试性测试策略纯函数无副作用高直接断言输入/输出无需 mockReact 组件中可能需要 mock 依赖与渲染环境依赖外部模块/API 的函数低必须明确列出需要 mock 的依赖仓库中的 frontend/common/utils/format.ts 是“高可测试性”的典型它导出一个Format对象包含shortenNumber、camelCase、enumeration、fullName、truncateText、trimAndHighlightSpaces、userDisplayName等纯函数无任何外部导入因此其测试format.test.ts完全不需要 mock。相反frontend/common/utils/featureFilterParams.ts 导入了FEATURES_PAGE_SIZE来自common/services/useProjectFlag以及类型常量其测试featureFilterParams.test.ts在文件顶部使用jest.mock(common/services/useProjectFlag, ...)切断了这一依赖链——这正是“依赖外部模块时注明 mock 目标”的教科书式做法。四、第三步生成测试文件——位置约定与路径别名命令规定了测试文件的生成位置与导入规范位置{sourceDir}/__tests__/{filename}.test.ts即与源文件同目录的__tests__子目录导入必须使用路径别名common/...、components/...等而非冗长的相对路径。路径别名的解析由 frontend/jest.config.js 的moduleNameMapper提供moduleNameMapper: { ^common/(.*)$: rootDir/common/$1, ^components/(.*)$: rootDir/web/components/$1, ^project/(.*)$: rootDir/web/project/$1, // webpack resolves this one too; without it jest cannot follow the app. ^web/(.*)$: rootDir/web/$1, },该映射与前端构建工具rspack的路径解析保持一致保证同一套别名在测试与生产构建中指向相同文件。例如import Format from common/utils/format会被解析到frontend/common/utils/format.ts。五、第四步测试结构要求——describe、it.each 与边界用例命令对测试结构提出三条硬性要求这是 Flagsmith 前端单测的代码风格基准每个导出函数一个describe块多输入/输出用例使用it.each表驱动测试必须覆盖边界用例null、undefined、空字符串、空数组以及适用场景下的数值边界。format.test.ts 完整示范了这三条规则。以shortenNumber为例其边界覆盖极其彻底——既有正常量级1000 → 1K、123456 → 123.5K也有0、null、undefined、NaN、Infinity、-Infinity全部异常输入describe(shortenNumber, () { it.each input | expected ${1523125} | ${1.5M} ${1500} | ${1.5K} ${1500000000000} | ${1.5T} ${1000} | ${1K} ${12345} | ${12.3K} ${0} | ${0} ${undefined} | ${0} ${null} | ${0} ${NaN} | ${0} ${Infinity} | ${0} ${-Infinity} | ${0} (shortenNumber($input) returns $expected, ({ expected, input }) { expect(Format.shortenNumber(input)).toBe(expected) }) })对照源码format.ts可以发现测试设计是有意为之shortenNumber内部对输入执行Math.log10因此0与缺失值会导致 NaN源码以if (!number || !Number.isFinite(number)) return 0做了防御而测试正是为验证这些防御分支而设计——测试用例应当从源码的边界分支反推而来。camelCase、enumeration、fullName、truncateText、trimAndHighlightSpaces、userDisplayName的测试块同样遵循此模式其中fullName覆盖了“只有 firstName”“只有 lastName”“空对象”“null/undefined”等组合验证了源码中fn ? ... : ...的三路分支。六、测试文件模板精讲命令文档给出了一份可直接套用的最小模板其要点值得逐行拆解import { functionName } from common/path/to/file describe(functionName, () { it.each input | expected ${value1} | ${result1} ${value2} | ${result2} ${null} | ${expectedForNull} ${undefined} | ${expectedForUndefined} (functionName($input) returns $expected, ({ input, expected }) { expect(functionName(input)).toBe(expected) }) })import { functionName } from common/path/to/file使用路径别名导入被测函数而非相对路径it.each搭配标记模板字符串tagged template写法表格首行为参数名${...}内插值为用例数据测试名称中可用$input、$expected动态引用当前行的值失败时 Jest 会自动生成带具体参数的用例名便于定位解构参数({ input, expected })it.each的表格对象会作为参数传入回调测试名称模板functionName($input) returns $expected使每个用例的断言意图一目了然expect(...).toBe(...)纯函数断言默认使用严格相等若涉及对象比较则应换用toEqual。七、第五步运行测试并验证生成测试后命令要求立即运行验证指定命令为npm run test:unit -- --testPathPatterns{filename}该命令的执行链路为npm run test:unit在 frontend/package.json 中定义为jest随后--testPathPatterns{filename}作为参数透传给 Jest用于只运行与目标文件名匹配的测试文件从而把验证范围收敛到刚生成的测试上。仓库还提供了配套的运行与反馈手段命令作用npm run test:unit执行全部 Jest 单元测试等价于jestnpm run test:unit:watch监听模式jest --watch开发期迭代测试npm run test:unit:coverage生成覆盖率报告jest --coverage覆盖率收集范围同样由 frontend/jest.config.js 定义collectCoverageFrom: [ common/**/*.{ts,tsx}, web/**/*.{ts,tsx}, !**/*.d.ts, !**/node_modules/**, ], coverageDirectory: coverage,即只统计common与web下的业务源码排除类型声明与依赖输出到coverage/目录可据此评估“检查现有测试、定位覆盖缺口”这一步骤的执行效果。八、进阶依赖注入与 mock 策略当被测模块依赖外部服务时表驱动测试无法独立完成需要 mock。命令文档的参考范例 featureFilterParams.test.ts 展示了三种实战手法1. 模块级 mock 切断深层依赖链——文件首行即声明// Mock useProjectFlag to avoid deep dependency chain with legacy JS files jest.mock(common/services/useProjectFlag, () ({ FEATURES_PAGE_SIZE: 100, }))这是对第 2 步“注明需要 mock 的依赖”的执行featureFilterParams.ts从useProjectFlag导入FEATURES_PAGE_SIZE而后者可能牵连 legacy JS 文件故直接以常量替换。2. 工厂函数构造测试态——createDefaultFilters(overrides)以默认值展开再合并覆盖项使得每个用例只需表达“与默认状态的差异”const createDefaultFilters (overrides?: PartialFilterState): FilterState ({ group_owners: [], is_enabled: null, owners: [], search: null, showArchived: false, sort: { label: Name, sortBy: name, sortOrder: SortOrder.ASC }, tag_strategy: TagStrategy.INTERSECTION, tags: [], value_search: , ...overrides, })3. 以回调注入替代真实服务——buildApiFilterParams接受getEnvironmentIdFromKey: (apiKey: string) number | undefined类型的解析器源码中定义为EnvironmentIdResolver见 featureFilterParams.ts测试只需传入一个 mock 函数即可验证“key 无法解析时返回null”“可解析时携带environmentId/projectId”等分支const mockResolver (apiKey: string) apiKey test-key ? 123 : undefined it(returns null when environment ID cannot be resolved, () { const result buildApiFilterParams(createDefaultFilters(), 1, invalid-key, 1, mockResolver) expect(result).toBeNull() })该文件还对buildUrlParams、getFiltersFromParams、normaliseFilters、hasActiveFilters分别建立describe块完整覆盖 URL 参数序列化与反序列化、空白搜索词归一化、默认状态无活动筛选等行为是“每个导出函数一个 describe”与“边界用例”要求的综合范例。九、Jest 运行环境配置要点要让上述测试模板在 Flagsmith 前端仓库中稳定运行还需了解三份配置的协作关系frontend/jest.config.js定义preset: ts-jest、moduleNameMapper路径别名、testMatch测试发现规则以及clearMocks: true自动清理 mock 状态避免用例间串扰frontend/tsconfig.jest.json继承根tsconfig.json并追加jsx: react-jsx供 ts-jest 转换 React 组件测试使用transform 配置对.js/.jsx/.ts/.tsx统一走 ts-jest 转换transformIgnorePatterns: [/node_modules/]保持依赖不转换注释特别说明 code-help 中的 ESM 模板片段需要转换故仅排除 node_modules。仓库中 frontend/common/hooks/tests/ 下的useHasFeatureStateChanges.test.ts、useFeatureExperimentFreeze.test.ts等文件则展示了 React Hooks 场景的多重 mock 手法同时 mockreact、common/store、多个 services可视为组件/钩子类文件测试的进阶参考。十、生成与评审的自检清单综合命令文档的步骤与仓库实践每次生成前端单测可按下表自查位置是否落在{sourceDir}/__tests__/{filename}.test.ts导入是否全部使用common/...、components/...等路径别名结构每个导出函数是否都有独立describe多用例是否改用it.each边界null、undefined、空串、空数组是否已覆盖数值函数是否覆盖0/NaN/Infinity依赖外部依赖是否已 mock是否存在可注入的回调以简化 mock验证是否运行npm run test:unit -- --testPathPatterns{filename}确认全绿遵循这套工作流即可在 Flagsmith 这类规模较大、模块划分清晰common/utils、common/hooks、web/components的前端仓库中稳定产出结构统一、边界完备、可读性强的 Jest 单元测试。赞分享后端前端【免费下载链接】flagsmithFlagsmith is an open-source feature flag platform with remote config, experimentation, and self-hosted or cloud deployment options.项目地址https://gitcode.com/gh_mirrors/fl/flagsmith点击查看免费下载相关推荐Whomane单元测试指南Jest与PyTest实现前后端代码覆盖Whomane单元测试指南Jest与PyTest实现前后端代码覆盖 测试架构概览 Whomane项目采用前后端分离架构前端使用TypeScript构建ReaGriddyCode测试集成单元测试与代码覆盖率GriddyCode测试集成单元测试与代码覆盖率 痛点为什么代码编辑器需要测试框架 你还在手动测试代码编辑器的每个功能吗当添加新语法高亮或主题时是否担免费完整导出QQ空间历史说说使用指南免费完整导出QQ空间历史说说使用指南 想把 QQ 空间的历史说说归档成本地文件开源项目 GetQzonehistory 是目前最省事的做法。手机扫码登录后它网页爬虫数据分析上一篇CouchDB 集群节点管理实战通过 _membership 与 _nodes 数据库安全地添加和移除节点下一篇ThinkPad风扇终极控制TPFanControl2完全使用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考