Baserow 前端单元测试实践Vitest、TestApp 与 Nuxt mountSuspended 四层测试模式【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow在 Baserow 仓库中编写前端单元测试时最大的陷阱是“自创一套 Vue 测试风格”。这套 Skill 文档位于 .agents/skills/write-frontend-unit-test/SKILL.md给出的核心方法论是仓库内已经沉淀了成熟的 Vitest Vue Test Utils Nuxt Test Utils 测试基础设施新增或修改web-frontend、premium/web-frontend、enterprise/web-frontend三个前端包中的任何测试时必须先找到最近的现有 spec 并复制它的组织方式。读完本文你将掌握如何为 Baserow 的纯函数、Vuex store、共享 App 上下文组件和 Nuxt/Vue 3 组件分别选择正确的测试模式如何复用TestApp/PremiumTestApp/MockServer等仓库助手完成挂载与清理以及如何用just f yarn test:*命令精确运行单条 spec 验证结果。第一步先识别测试目标类型动笔之前先判断被测对象属于以下五类中的哪一类然后到对应模块目录下检索最近的现有 spec纯工具函数或解析器函数如modules/*/utils/**下的代码Vuex store 逻辑挂载了共享 App 上下文的 Vue 组件用mountSuspended直接挂载的 Nuxt/Vue 3 组件以上任一类的 Premium 或 Enterprise 变体。文档给出了三条常用的仓库级检索命令帮助快速定位可参照的 specrg可用时可作为grep -RInE的更快替代# 找到所有 spec 文件 find web-frontend/test premium/web-frontend/test enterprise/web-frontend/test -type f | grep \.spec\. # 找到使用 TestApp / PremiumTestApp / mountSuspended 的测试 grep -RInE new TestApp\(|new PremiumTestApp\(|mountSuspended\( web-frontend/test premium/web-frontend/test enterprise/web-frontend/test # 找到断言风格snapshot / vi.fn / spyOn grep -RInE toMatchSnapshot\(|vi\.fn\(|vi\.spyOn\( web-frontend/test premium/web-frontend/test enterprise/web-frontend/test这三类检索分别回答了“spec 分布在哪”“哪些文件用了 App 级助手”“哪些测试依赖快照或 spy 断言”三个问题是确定新测试应该模仿哪个模板的最快路径。测试工具链与全局环境当前前端单元测试使用的技术栈为vitest提供describe、test、expect、vivue/test-utils组件挂载与 DOM 断言nuxt/test-utils/runtime的mountSuspended挂载依赖 Nuxt 上下文的 Vue 3 组件仓库自有助手TestApp、PremiumTestApp、MockServer以及web-frontend/test/fixtures下的数据夹具组件渲染结果相关场景使用快照断言。关键文件有三个web-frontend/vitest.setup.tsweb-frontend/test/helpers/testApp.jspremium/web-frontend/test/helpers/premiumTestApp.jsvitest.setup.ts 已经替你 Mock 了什么vitest.setup.ts 是全局 setup 文件在 web-frontend/vitest.config.base.ts 中通过setupFiles: [./vitest.setup.ts]挂载它统一处理了三件事测试代码里不要再重复 Mocki18nMock 掉vue-i18n的createI18n与useI18n让缺失的翻译 key 直接返回 key 本身t: (key) key并把浏览器 locale 固定为en。因此测试里断言文案时写的是 i18n key而不是翻译结果UUIDMockbaserow/modules/core/utils/string的uuid返回00000000-0000-0000-0000-000000000001这样的确定性序号 UUIDvi.hoisted维护计数且beforeEach中reset()保证同一次渲染中多个 UUID 稳定可断言WebSocketglobal.WebSocket被替换为只有空close()/send()的桩类注释明确说明“实时通道无法在单元测试中测”另外把 Vue Test Utils 的全局 stub 中加了Teleport: true并注入了一个会主动expect失败的global.fail供拦截器在意外错误时抛出清晰信号。同时 vitest.config.base.ts 决定了测试运行的整体环境environment: nuxtDOM 用happy-dom、pool: forks、isolate: true、testTimeout: 30_000与hookTimeout: 120_000注释说明 Nuxt 环境下 CI 默认超时不够用、测试时区固定 UTC、include: [./**/*.spec.js]。值得注意的一点是runtimeConfig.public.featureFlags: *——测试中默认开启所有 feature flag行为与后端测试配置对齐。模式一纯工具函数测试对于modules/*/utils/**下的函数保持最简形态直接 import 函数、用确定性输入、用toStrictEqual/toBe或显式构造的期望对象断言优先不拍快照。以 web-frontend/test/unit/core/utils/date.spec.js 为例它测试getDateInTimezone与getMonthlyTimestamps把返回的 Date 对象先转成toISOString()或显式字段对象再与一个纯字面量对象toStrictEqualexpect(monthlyTimestampsFormatted).toStrictEqual({ firstDayNextMonth: 2023-04-01T00:00:00.000Z, firstDayPreviousMonth: 2023-02-01T00:00:00.000Z, fromTimestamp: 2023-02-27T00:00:00.000Z, toTimestamp: 2023-04-03T00:00:00.000Z, firstMondayDayOfRange: 27, visibleNumberOfDaysFromNextMonth: 2, visibleNumberOfDaysFromPreviousMonth: 2, })同类参考还有 web-frontend/test/unit/core/utils/string.spec.js。这种测试不依赖TestApp文件越薄越好。模式二Vuex store 测试Store 行为测试优先使用TestApp除非现有 spec 明确是临时自建本地 store。标准四步beforeEach中testApp new TestApp()store testApp.store拿到已装好 Baserow 插件的 store通过 store actions 或testApp.mockServer填充状态afterEach中必须await testApp.afterEach()。以 web-frontend/test/unit/core/store/auth.spec.js 为范本beforeEach里创建TestApp用auth/forceSetUserData灌入伪造用户与 access_token各用例只测试auth/forceUpdateUserData的合并语义如“多次更新会 deep merge”“数组字段是覆盖而非合并”“可以显式设为 false”。注意这里反复出现的写法const additionalData store.getters[auth/getAdditionalUserData] expect(JSON.parse(JSON.stringify(additionalData))).toStrictEqual({ ... })Skill 文档特别说明对响应式 store 对象做JSON.parse(JSON.stringify(value))归一化是仓库里既有的惯例用于规避 Vue 响应式代理对深比较的干扰只在你参照的邻近测试也这么做时才使用不要全局推广。当被测代码在 premium 且依赖 premium 专属的 auth/license 行为时改用 PremiumTestApp。它是TestApp的子类把setupMockServer()替换为 premium 版MockPremiumServer并额外提供了四个注入许可状态的助手class PremiumTestApp extends TestApp { createTestUserInAuthStore() { ... } // 用 forceSetUserData 灌入固定测试用户 giveCurrentUserGlobalPremiumFeatures() { ... } // instance_wide 级 premium 许可 giveCurrentUserPremiumFeatureForSpecificWorkspaceOnly(workspaceId) { ... } // 单 workspace 许可 updateCurrentUserToBecomeStaffMember() { ... } // is_staff: true }这让“有/没有某级许可”的分支测试无需手工拼active_licenses结构。模式三共享 App 上下文组件测试TestApp.mount对大量组件——尤其是与 store、router、registry 或 client 强耦合的“旧模式”组件——做法是beforeEach中new TestApp()或new PremiumTestApp()用testApp.mount(Component, { props, propsData, slots, listeners, global })挂载文件里如果已有mountComponent(...)之类的局部封装优先复用afterEach清理。从 testApp.js 源码看新版TestApp基于useNuxtApp()拿到真实的$client、$store、$registry其mount()内部走mountSuspended并做了两件对迁移旧测试很重要的兼容props与 Nuxt 2 时代的propsData等价取propsData ?? propslisteners会被listenersToProps()转成 Vue 3 的onXxx事件 propitem-select变成onItemSelect形式。所以老 spec 的写法可以直接跑不必重写。TestApp还暴露testApp.mock挂在$client上的axios-mock-adapteronNoMatch: throwException未 mock 的请求会直接抛错testApp.mockServerMockServer(this.mock, this.$store)见 web-frontend/test/fixtures/mockServer.js。其头部注释说明了设计动机——把对后端 API 的 mock 收敛到单一类API 变更时只改这一处它内部基于createApplication、createWorkspace、createGridView、createFields、createGridRows等 fixtures 构造一致性的初始数据testApp.dontFailOnErrorResponses()默认情况下响应拦截器会让错误响应直接throw error只有测试故意验证失败响应路径时才临时关掉这个开关testApp.bodydocument.body的DOMWrapper用于检查直接 append 到 body 的弹层testApp.createStore(...)需要临时自建 store 时用它会把$i18n、$config、$client、$registry、$router、runWithContext一并补齐。afterEach()的清理逻辑值得逐条对应理解eject响应拦截器 →unmount所有 wrapper →store.replaceState回滚到构造时的_initialCleanStoreState→mock.restore()→router.replace(/)复位路由 →flushPromises()。正因如此Skill 文档把“用了TestApp却没写afterEach清理”列为硬性禁令不回滚 state 会让用例之间相互污染。该模式的标准样例web-frontend/test/unit/core/components/dropdown.spec.js 与 premium/web-frontend/test/unit/premium/view/calendar/calendarView.spec.js。模式四mountSuspended 直挂的 Nuxt/Vue 3 组件测试对较新的、不需要完整TestApp包装的 Nuxt/Vue 3 组件可以直接使用mountSuspended如果组件依赖注入的 app/store 上下文beforeEach中const testApp useNuxtApp()mountSuspended(Component, { props, slots, global: { provide, stubs, mocks } })挂载需要的注入项通过global.provide显式提供。以 web-frontend/test/unit/builder/components/elements/components/HeadingElement.spec.js 为完整范本它的结构是beforeEach(() { testApp useNuxtApp() store testApp.$store }) const mountComponent ({ props {}, slots {}, provide {} }) { return mountSuspended(HeadingElement, { props, slots, global: { provide }, }) } test(Default HeadingElement component, async () { const wrapper await mountComponent({ props: { element }, provide: { builder, mode, currentPage: page, elementPage: page, applicationContext, element, workspace }, }) expect(wrapper.element).toMatchSnapshot() })注意这里把builder、mode、applicationContext等依赖全部通过provide手工注入——这正是“直接提供注入依赖”原则的体现不依赖完整 App 装配测试边界更窄、失败定位更快。对这类纯渲染组件快照断言toMatchSnapshot()是仓库既有做法渲染结果变化时按“审查 diff 而非盲目接受”的原则处理。断言与 Mock 准则断言方面选能证明行为的最窄断言转换后的数据与 store 状态toStrictEqual/toEqual标量toBe事件处理与方法调用vi.fn()与vi.spyOn()仓库已在用的渲染 markup 场景快照。两条反模式纯逻辑不要默认拍快照不要断言内部状态要断言 DOM 可见结果。文档给出的反例是直接读wrapper.vmexpect(wrapper.vm.values.use_instance_smtp_settings).toBe(false) // BAD正确做法是通过wrapper.get(...)拿到 DOM 节点再断言其文本/属性。Mock 与夹具方面优先仓库助手拒绝“自造大 mock 环境”行为依赖 store 背后的 API 调用时用testApp.mockServer数据结构用 web-frontend/test/fixtures 下的 fixtures以及 premium/enterprise 各自的 fixture 目录只有故意测试失败响应时才testApp.dontFailOnErrorResponses()。从MockServer的实现看web-frontend/test/fixtures/mockServer.js它导入createApplication、createWorkspace、createGridView/createPublicGridView、createFields、createGridRows/createGalleryRows、expectUserUpdated等工厂函数——测试里“创建一个带两列三行的 workspace”这类前置数据都是通过这些工厂函数组装的而不是手拼 JSON。文件放置规范跟随既有测试树spec 与被测功能区就近放置不新建泛化的测试目录Coreweb-frontend/test/unit/...Premiumpremium/web-frontend/test/unit/...Enterpriseenterprise/web-frontend/test/unit/...例如 grid 相关组件的测试放在web-frontend/test/unit/core/components/下builder 的 store 测试放在web-frontend/test/unit/builder/store/下保持目录镜像模块结构。运行验证最窄范围命令优先验证时先跑与改动相关的最小测试集仓库用just fjustfile中alias f : frontend在 web-frontend 包内执行 yarn 脚本对应 web-frontend/package.json 中的三个脚本均带NODE_OPTIONS--max-old-space-size8192premium/enterprise 通过--config ../pkg/web-frontend/vitest.config.ts复用同一 vitest 安装just f yarn test:core --run test/unit/core/components/dropdown.spec.js just f yarn test:core --run test/unit/core/store/auth.spec.js just f yarn test:premium --run ../premium/web-frontend/test/unit/premium/view/calendar/calendarView.spec.js just f yarn test:enterprise --run ../enterprise/web-frontend/test/unit/enterprise/plugins.spec.js注意--run单次运行而非 watch与路径基准test:core相对web-frontend/而test:premium/test:enterprise需要相对web-frontend/的上行路径../pkg/web-frontend/test/...。若快照是有意变更的先审查 diff 再更新不要无脑 accept。护栏清单GuardrailsSkill 文档最后列出的七条红线可视为 code review 自查项不引入 Jest API只用仓库现存的 Vitest APIvi.fn、vi.spyOn、vi.mock等有TestApp/PremiumTestApp可用时不再新增独立 mount 助手真实助手能提供的 store/router/client 依赖不做过度 mock一个文件里不混用风格跟随最近邻 spec使用TestApp/PremiumTestApp时不得遗漏afterEach清理能用聚焦单测解决时不写宽泛的集成式测试。配合 vitest.config.base.ts 中include: [./**/*.spec.js]与**/test/server/**的排除规则可以推断只有命名为*.spec.js的文件才会被拾取遗留的 Nuxt 2 风格 server 测试已被明确排除新测试命名必须遵循*.spec.js约定。综上Baserow 前端单测体系的精髓在于“约束先行”全局 setup 统一了 i18n/UUID/WebSocket 三个不稳定源TestApp统一了 store 装配与清理MockServer统一了 API 边界PremiumTestApp统一了许可状态注入写新测试时的工作不是发明新工具而是找到最接近的现有 spec复制其形状然后在窄范围内写清行为断言。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Baserow 前端单元测试实践：Vitest、TestApp 与 Nuxt mountSuspended 四层测试模式
Baserow 前端单元测试实践Vitest、TestApp 与 Nuxt mountSuspended 四层测试模式【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow在 Baserow 仓库中编写前端单元测试时最大的陷阱是“自创一套 Vue 测试风格”。这套 Skill 文档位于 .agents/skills/write-frontend-unit-test/SKILL.md给出的核心方法论是仓库内已经沉淀了成熟的 Vitest Vue Test Utils Nuxt Test Utils 测试基础设施新增或修改web-frontend、premium/web-frontend、enterprise/web-frontend三个前端包中的任何测试时必须先找到最近的现有 spec 并复制它的组织方式。读完本文你将掌握如何为 Baserow 的纯函数、Vuex store、共享 App 上下文组件和 Nuxt/Vue 3 组件分别选择正确的测试模式如何复用TestApp/PremiumTestApp/MockServer等仓库助手完成挂载与清理以及如何用just f yarn test:*命令精确运行单条 spec 验证结果。第一步先识别测试目标类型动笔之前先判断被测对象属于以下五类中的哪一类然后到对应模块目录下检索最近的现有 spec纯工具函数或解析器函数如modules/*/utils/**下的代码Vuex store 逻辑挂载了共享 App 上下文的 Vue 组件用mountSuspended直接挂载的 Nuxt/Vue 3 组件以上任一类的 Premium 或 Enterprise 变体。文档给出了三条常用的仓库级检索命令帮助快速定位可参照的 specrg可用时可作为grep -RInE的更快替代# 找到所有 spec 文件 find web-frontend/test premium/web-frontend/test enterprise/web-frontend/test -type f | grep \.spec\. # 找到使用 TestApp / PremiumTestApp / mountSuspended 的测试 grep -RInE new TestApp\(|new PremiumTestApp\(|mountSuspended\( web-frontend/test premium/web-frontend/test enterprise/web-frontend/test # 找到断言风格snapshot / vi.fn / spyOn grep -RInE toMatchSnapshot\(|vi\.fn\(|vi\.spyOn\( web-frontend/test premium/web-frontend/test enterprise/web-frontend/test这三类检索分别回答了“spec 分布在哪”“哪些文件用了 App 级助手”“哪些测试依赖快照或 spy 断言”三个问题是确定新测试应该模仿哪个模板的最快路径。测试工具链与全局环境当前前端单元测试使用的技术栈为vitest提供describe、test、expect、vivue/test-utils组件挂载与 DOM 断言nuxt/test-utils/runtime的mountSuspended挂载依赖 Nuxt 上下文的 Vue 3 组件仓库自有助手TestApp、PremiumTestApp、MockServer以及web-frontend/test/fixtures下的数据夹具组件渲染结果相关场景使用快照断言。关键文件有三个web-frontend/vitest.setup.tsweb-frontend/test/helpers/testApp.jspremium/web-frontend/test/helpers/premiumTestApp.jsvitest.setup.ts 已经替你 Mock 了什么vitest.setup.ts 是全局 setup 文件在 web-frontend/vitest.config.base.ts 中通过setupFiles: [./vitest.setup.ts]挂载它统一处理了三件事测试代码里不要再重复 Mocki18nMock 掉vue-i18n的createI18n与useI18n让缺失的翻译 key 直接返回 key 本身t: (key) key并把浏览器 locale 固定为en。因此测试里断言文案时写的是 i18n key而不是翻译结果UUIDMockbaserow/modules/core/utils/string的uuid返回00000000-0000-0000-0000-000000000001这样的确定性序号 UUIDvi.hoisted维护计数且beforeEach中reset()保证同一次渲染中多个 UUID 稳定可断言WebSocketglobal.WebSocket被替换为只有空close()/send()的桩类注释明确说明“实时通道无法在单元测试中测”另外把 Vue Test Utils 的全局 stub 中加了Teleport: true并注入了一个会主动expect失败的global.fail供拦截器在意外错误时抛出清晰信号。同时 vitest.config.base.ts 决定了测试运行的整体环境environment: nuxtDOM 用happy-dom、pool: forks、isolate: true、testTimeout: 30_000与hookTimeout: 120_000注释说明 Nuxt 环境下 CI 默认超时不够用、测试时区固定 UTC、include: [./**/*.spec.js]。值得注意的一点是runtimeConfig.public.featureFlags: *——测试中默认开启所有 feature flag行为与后端测试配置对齐。模式一纯工具函数测试对于modules/*/utils/**下的函数保持最简形态直接 import 函数、用确定性输入、用toStrictEqual/toBe或显式构造的期望对象断言优先不拍快照。以 web-frontend/test/unit/core/utils/date.spec.js 为例它测试getDateInTimezone与getMonthlyTimestamps把返回的 Date 对象先转成toISOString()或显式字段对象再与一个纯字面量对象toStrictEqualexpect(monthlyTimestampsFormatted).toStrictEqual({ firstDayNextMonth: 2023-04-01T00:00:00.000Z, firstDayPreviousMonth: 2023-02-01T00:00:00.000Z, fromTimestamp: 2023-02-27T00:00:00.000Z, toTimestamp: 2023-04-03T00:00:00.000Z, firstMondayDayOfRange: 27, visibleNumberOfDaysFromNextMonth: 2, visibleNumberOfDaysFromPreviousMonth: 2, })同类参考还有 web-frontend/test/unit/core/utils/string.spec.js。这种测试不依赖TestApp文件越薄越好。模式二Vuex store 测试Store 行为测试优先使用TestApp除非现有 spec 明确是临时自建本地 store。标准四步beforeEach中testApp new TestApp()store testApp.store拿到已装好 Baserow 插件的 store通过 store actions 或testApp.mockServer填充状态afterEach中必须await testApp.afterEach()。以 web-frontend/test/unit/core/store/auth.spec.js 为范本beforeEach里创建TestApp用auth/forceSetUserData灌入伪造用户与 access_token各用例只测试auth/forceUpdateUserData的合并语义如“多次更新会 deep merge”“数组字段是覆盖而非合并”“可以显式设为 false”。注意这里反复出现的写法const additionalData store.getters[auth/getAdditionalUserData] expect(JSON.parse(JSON.stringify(additionalData))).toStrictEqual({ ... })Skill 文档特别说明对响应式 store 对象做JSON.parse(JSON.stringify(value))归一化是仓库里既有的惯例用于规避 Vue 响应式代理对深比较的干扰只在你参照的邻近测试也这么做时才使用不要全局推广。当被测代码在 premium 且依赖 premium 专属的 auth/license 行为时改用 PremiumTestApp。它是TestApp的子类把setupMockServer()替换为 premium 版MockPremiumServer并额外提供了四个注入许可状态的助手class PremiumTestApp extends TestApp { createTestUserInAuthStore() { ... } // 用 forceSetUserData 灌入固定测试用户 giveCurrentUserGlobalPremiumFeatures() { ... } // instance_wide 级 premium 许可 giveCurrentUserPremiumFeatureForSpecificWorkspaceOnly(workspaceId) { ... } // 单 workspace 许可 updateCurrentUserToBecomeStaffMember() { ... } // is_staff: true }这让“有/没有某级许可”的分支测试无需手工拼active_licenses结构。模式三共享 App 上下文组件测试TestApp.mount对大量组件——尤其是与 store、router、registry 或 client 强耦合的“旧模式”组件——做法是beforeEach中new TestApp()或new PremiumTestApp()用testApp.mount(Component, { props, propsData, slots, listeners, global })挂载文件里如果已有mountComponent(...)之类的局部封装优先复用afterEach清理。从 testApp.js 源码看新版TestApp基于useNuxtApp()拿到真实的$client、$store、$registry其mount()内部走mountSuspended并做了两件对迁移旧测试很重要的兼容props与 Nuxt 2 时代的propsData等价取propsData ?? propslisteners会被listenersToProps()转成 Vue 3 的onXxx事件 propitem-select变成onItemSelect形式。所以老 spec 的写法可以直接跑不必重写。TestApp还暴露testApp.mock挂在$client上的axios-mock-adapteronNoMatch: throwException未 mock 的请求会直接抛错testApp.mockServerMockServer(this.mock, this.$store)见 web-frontend/test/fixtures/mockServer.js。其头部注释说明了设计动机——把对后端 API 的 mock 收敛到单一类API 变更时只改这一处它内部基于createApplication、createWorkspace、createGridView、createFields、createGridRows等 fixtures 构造一致性的初始数据testApp.dontFailOnErrorResponses()默认情况下响应拦截器会让错误响应直接throw error只有测试故意验证失败响应路径时才临时关掉这个开关testApp.bodydocument.body的DOMWrapper用于检查直接 append 到 body 的弹层testApp.createStore(...)需要临时自建 store 时用它会把$i18n、$config、$client、$registry、$router、runWithContext一并补齐。afterEach()的清理逻辑值得逐条对应理解eject响应拦截器 →unmount所有 wrapper →store.replaceState回滚到构造时的_initialCleanStoreState→mock.restore()→router.replace(/)复位路由 →flushPromises()。正因如此Skill 文档把“用了TestApp却没写afterEach清理”列为硬性禁令不回滚 state 会让用例之间相互污染。该模式的标准样例web-frontend/test/unit/core/components/dropdown.spec.js 与 premium/web-frontend/test/unit/premium/view/calendar/calendarView.spec.js。模式四mountSuspended 直挂的 Nuxt/Vue 3 组件测试对较新的、不需要完整TestApp包装的 Nuxt/Vue 3 组件可以直接使用mountSuspended如果组件依赖注入的 app/store 上下文beforeEach中const testApp useNuxtApp()mountSuspended(Component, { props, slots, global: { provide, stubs, mocks } })挂载需要的注入项通过global.provide显式提供。以 web-frontend/test/unit/builder/components/elements/components/HeadingElement.spec.js 为完整范本它的结构是beforeEach(() { testApp useNuxtApp() store testApp.$store }) const mountComponent ({ props {}, slots {}, provide {} }) { return mountSuspended(HeadingElement, { props, slots, global: { provide }, }) } test(Default HeadingElement component, async () { const wrapper await mountComponent({ props: { element }, provide: { builder, mode, currentPage: page, elementPage: page, applicationContext, element, workspace }, }) expect(wrapper.element).toMatchSnapshot() })注意这里把builder、mode、applicationContext等依赖全部通过provide手工注入——这正是“直接提供注入依赖”原则的体现不依赖完整 App 装配测试边界更窄、失败定位更快。对这类纯渲染组件快照断言toMatchSnapshot()是仓库既有做法渲染结果变化时按“审查 diff 而非盲目接受”的原则处理。断言与 Mock 准则断言方面选能证明行为的最窄断言转换后的数据与 store 状态toStrictEqual/toEqual标量toBe事件处理与方法调用vi.fn()与vi.spyOn()仓库已在用的渲染 markup 场景快照。两条反模式纯逻辑不要默认拍快照不要断言内部状态要断言 DOM 可见结果。文档给出的反例是直接读wrapper.vmexpect(wrapper.vm.values.use_instance_smtp_settings).toBe(false) // BAD正确做法是通过wrapper.get(...)拿到 DOM 节点再断言其文本/属性。Mock 与夹具方面优先仓库助手拒绝“自造大 mock 环境”行为依赖 store 背后的 API 调用时用testApp.mockServer数据结构用 web-frontend/test/fixtures 下的 fixtures以及 premium/enterprise 各自的 fixture 目录只有故意测试失败响应时才testApp.dontFailOnErrorResponses()。从MockServer的实现看web-frontend/test/fixtures/mockServer.js它导入createApplication、createWorkspace、createGridView/createPublicGridView、createFields、createGridRows/createGalleryRows、expectUserUpdated等工厂函数——测试里“创建一个带两列三行的 workspace”这类前置数据都是通过这些工厂函数组装的而不是手拼 JSON。文件放置规范跟随既有测试树spec 与被测功能区就近放置不新建泛化的测试目录Coreweb-frontend/test/unit/...Premiumpremium/web-frontend/test/unit/...Enterpriseenterprise/web-frontend/test/unit/...例如 grid 相关组件的测试放在web-frontend/test/unit/core/components/下builder 的 store 测试放在web-frontend/test/unit/builder/store/下保持目录镜像模块结构。运行验证最窄范围命令优先验证时先跑与改动相关的最小测试集仓库用just fjustfile中alias f : frontend在 web-frontend 包内执行 yarn 脚本对应 web-frontend/package.json 中的三个脚本均带NODE_OPTIONS--max-old-space-size8192premium/enterprise 通过--config ../pkg/web-frontend/vitest.config.ts复用同一 vitest 安装just f yarn test:core --run test/unit/core/components/dropdown.spec.js just f yarn test:core --run test/unit/core/store/auth.spec.js just f yarn test:premium --run ../premium/web-frontend/test/unit/premium/view/calendar/calendarView.spec.js just f yarn test:enterprise --run ../enterprise/web-frontend/test/unit/enterprise/plugins.spec.js注意--run单次运行而非 watch与路径基准test:core相对web-frontend/而test:premium/test:enterprise需要相对web-frontend/的上行路径../pkg/web-frontend/test/...。若快照是有意变更的先审查 diff 再更新不要无脑 accept。护栏清单GuardrailsSkill 文档最后列出的七条红线可视为 code review 自查项不引入 Jest API只用仓库现存的 Vitest APIvi.fn、vi.spyOn、vi.mock等有TestApp/PremiumTestApp可用时不再新增独立 mount 助手真实助手能提供的 store/router/client 依赖不做过度 mock一个文件里不混用风格跟随最近邻 spec使用TestApp/PremiumTestApp时不得遗漏afterEach清理能用聚焦单测解决时不写宽泛的集成式测试。配合 vitest.config.base.ts 中include: [./**/*.spec.js]与**/test/server/**的排除规则可以推断只有命名为*.spec.js的文件才会被拾取遗留的 Nuxt 2 风格 server 测试已被明确排除新测试命名必须遵循*.spec.js约定。综上Baserow 前端单测体系的精髓在于“约束先行”全局 setup 统一了 i18n/UUID/WebSocket 三个不稳定源TestApp统一了 store 装配与清理MockServer统一了 API 边界PremiumTestApp统一了许可状态注入写新测试时的工作不是发明新工具而是找到最接近的现有 spec复制其形状然后在窄范围内写清行为断言。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
