1. 项目概述与测试需求拆解
1.1 核心需求解析：为什么移动AI应用需要一份完整的Jest测试方案
PocketPal AI是我一直在维护的一个移动端轻量级AI助手项目，它的核心功能包括本地推理、上下文记忆、多轮对话管理，以及设备端模型调度。这类应用与普通工具类App最大的不同在于——它的核心逻辑高度依赖异步计算、状态变更频繁、且涉及大量不可控的外部依赖（比如模型文件加载、推理引擎初始化、网络请求兜底等等）。这些特性决定了它的测试难度远高于传统CRUD类应用。如果测试方案设计得不够系统，后期每迭代一个功能，回归成本都会成倍增长。
我最初接手这个项目时，测试覆盖率几乎是零。代码库里有大量的纯函数（比如上下文压缩、Token估算、消息排序），也有不少复杂的异步流程（比如模型切换、推理队列、断网重连），再加上React Native环境下原生模块与JavaScript层的桥接，整个测试复杂度非常高。如果只用常规的快照测试和浅渲染跑一遍，很多核心逻辑实际上等于裸奔。
后来我针对PocketPal AI搭了一套基于Jest的完整测试方案，核心原则可以概括成三个词：分层、插桩、可控。分层指的是把测试对象拆成纯函数层、状态管理层、UI组件层和端到端流程层；插桩指的是用Jest的Mock机制把所有外部不可控依赖（模型加载器、推理引擎、原生桥接模块）全部替换成可控桩件；可控指的是对异步逻辑的时序进行显式编排，不让任何测试依赖“碰运气式”的等待策略。
这套方案跑通之后，PocketPal AI的测试用例规模从不到20个扩展到了300多个，单次全量测试的执行时间稳定在3分钟左右，CI流水线里每次提交都能自动跑完。这篇文章我就把这套方案的完整设计思路、配置方法和实操细节整理出来，希望对正在做移动AI应用测试的同学有参考价值。
1.2 适用场景与预期效果：这套方案能解决什么问题
先说清楚这套方案适合谁、不适合谁。如果你开发的是一个纯前端展示类应用，组件渲染逻辑简单、异步调用少，那用Jest做基础快照测试就够了，完全不需要搞这么重的分层体系。但如果你做的事和我一样——在移动端承载AI推理能力，需要处理模型下载、队列调度、内存预警、上下文管理等复杂状态，那这套方案就是为你准备的。
从预期效果来看，这套方案主要解决了三个痛点：
第一，异步流程的确定性。AI应用的典型特点是大量异步操作，比如模型加载要等数秒、推理结果要等回调、队列里可能有多个任务在排队。直接用真实依赖跑测试，要么测试时快时慢，要么偶发超时，CI里经常出现“上次过了这次挂了”的情况。通过Mock和定时器控制，我能让每一次测试都以完全一致的时序执行，彻底消除这种不确定性。
第二，外部依赖的可控性。PocketPal AI依赖原生模块进行模型推理，但Jest环境本身跑在Node.js上，根本没有原生桥接能力。我的方案是在测试环境里构建一个“模拟推理引擎”，它能够预定义返回结果、注入错误码、模拟耗时，让测试用例完全掌控推理行为。
第三，回归成本的可见性。有了覆盖率统计和分层测试结构之后，每次改动代码都能立刻知道哪些模块受影响。比如我改动了Token估算算法，跑一遍测试就知道上下文管理的相关用例是否全部通过，不再需要通过人工回归去猜。
提示：这套方案不是银弹。如果你的团队连基础的单元测试习惯都没有，建议先从小范围纯函数测试开始，逐步扩展，而不是一次性把所有基础设施全部铺开，否则维护成本会直接压垮团队。
2. 环境搭建与配置策略
2.1 依赖安装与初始化配置：从零搭起一个可运行的Jest环境
PocketPal AI采用的是React Native架构，所以测试环境搭建时需要同时考虑JavaScript层和原生层的隔离。我的基础依赖选择是Jest配合babel-jest做代码转换，再加@testing-library/react-native做组件测试，最后用jest-native的断言匹配器来增强可读性。下面是一个实际可用的安装组合：
npm install --save-dev jest babel-jest @babel/core @babel/preset-env @babel/preset-react @babel/preset-typescript @testing-library/react-native jest-native eslint-plugin-jest安装完成之后，核心配置文件是jest.config.js。针对PocketPal AI的实际情况，我的配置里有三个关键点需要特别说明。第一是testMatch范围，因为项目里同时存在单元测试和集成测试，我用不同的目录来区分：tests/unit放纯函数和状态管理的测试，tests/integration放跨模块联动的测试，而tests/e2e则留给需要真机环境的完整流程验证。Jest配置只需要指向这两个目录，避免误跑到构建产物里去执行测试。
第二是transformIgnorePatterns。React Native生态里有大量ESM格式的第三方库，Jest默认只转换JavaScript文件，但这些库发布到npm上的时候往往是未编译的ESM源码。如果不处理这个配置，测试跑起来会报“Unexpected token 'export'”之类的问题。我的做法是明确列出需要转换的依赖白名单，比如React Native、相关动画库、状态管理库等。
第三是setupFilesAfterFramework，这个是全局测试预处理钩子。我在这个文件里统一初始化Mock环境，配置异步API的polyfill，以及注册测试环境的清理函数。这样每个测试用例在执行前就已经具备了干净、可控的基础环境。
// jest.config.js module.exports = { preset: 'react-native', testEnvironment: 'node', testMatch: [ '<rootDir>/tests/unit/**/*.test.js', '<rootDir>/tests/integration/**/*.test.js' ], transformIgnorePatterns: [ 'node_modules/(?!(react-native|@react-native|react-native-reanimated|@testing-library)/)' ], setupFilesAfterFramework: ['<rootDir>/tests/setup.js'], moduleNameMapper: { '^@/(.*)$': '<rootDir>/src/$1' }, collectCoverageFrom: [ 'src/**/*.{js,jsx,ts,tsx}', '!src/**/*.d.ts', '!src/main.tsx', '!src/App.tsx' ], coverageThreshold: { global: { branches: 80, functions: 85, lines: 90, statements: 85 } } };提示：我的实际经验是coverageThreshold这个配置要从低到高逐步收紧。一开始就卡90%会把团队搞崩溃，建议先设定60%跑通流程，每两到三周往上调5到10个百分点，逐步养成测试习惯。
2.2 全局Mock方案设计：把外部依赖全部替换成可控桩件
Jest的Mock机制是整个测试方案的地基，在PocketPal AI这个项目里，需要Mock的依赖大致分为三类：原生桥接模块、模型推理相关模块、系统能力模块（比如文件系统、网络状态、存储等）。
先看原生桥接模块。React Native项目里经常通过NativeModules访问原生能力，在Jest环境下这些模块根本不存在，最简单的处理方式就是全局Mock。我在setup.js文件里统一对所有原生模块创建Mock，确保测试环境中所有require原生模块的代码都能正常工作。
第二个是模型推理相关模块的Mock。PocketPal AI的推理引擎暴露了loadModel、generate、cancelGeneration、getModelInfo等方法。在测试中，我构建了一个假引擎（FakeInferenceEngine），它能够预定义返回结果、注入错误码、记录调用参数，并且支持手动触发回调。这个假引擎是集成测试最核心的零件。
第三类是系统能力模块。文件系统读写、网络状态变化、本地存储读写这些能力在测试环境里都需要隔离。我分别对它们做了Mock实现，重点保证两个维度：一是所有Mock函数都能自动重置状态，避免用例之间的数据污染；二是Mock实现足够轻量，不会拖慢整体测试速度。
// tests/setup.js jest.mock('react-native/Libraries/NativeModules/NativeModules', () => ({ PocketPalNativeBridge: { loadModel: jest.fn(), generate: jest.fn(), cancelGeneration: jest.fn(), getDeviceMemoryStatus: jest.fn(() => Promise.resolve({ level: 'normal', used: 512 })) } }));这段代码看起来简单，但它解决了一个很关键的问题——所有测试用例里使用的原生桥接方法，都是同一个Mock实例。这样我可以在任何用例里通过require拿到对应的jest.fn()，对它进行断言（调用了多少次、用什么参数调用、返回值是什么）。
3. 测试策略与架构设计
3.1 分层测试体系：从纯函数到端到端流程的完整覆盖
PocketPal AI的测试策略不是一把抓的，而是像切豆腐一样把整个应用切成了四层，每一层有明确的测试目标和Mock策略。第一层是纯函数层，测试目标是所有不依赖外部I/O的工具函数，比如Token估算、上下文裁剪、消息格式化、温度参数映射等。这类测试写起来最简单，核心就是给定输入、断言输出，关键是覆盖边界条件。
第二层是状态管理层。PocketPal AI有全局状态管理，存着会话列表、当前活动会话、消息记录、模型参数、任务队列等。状态管理的测试核心是验证各个action和reducer对状态变更的正确性。我的做法是给每个action写三个维度的测试：正常操作下状态是否正确更新、边界参数下会不会抛异常、异步action里的错误分支是否正确处理。
第三层是组件层。组件测试主要验证UI与逻辑的交互，比如消息列表组件在收到新消息后是否重新渲染、发送按钮在输入为空时是否禁用、模型切换弹窗里的选项是否与当前可用模型一致。组件测试的关键是合理使用@testing-library/react-native提供的render与fireEvent，不去验证内部实现细节，只验证对外行为和交互结果。
第四层是流程集成测试。这是PocketPal AI整个测试方案里最复杂也最有价值的部分。集成测试会跨多个模块模拟一个完整的用户场景，比如“用户发送一条消息，模型加载完成后成功返回回复并插入消息列表”。这类测试需要把纯函数层、状态管理层和Mock的推理引擎全部串联起来，验证它们之间的协作是否顺畅。
这四层加在一起，形成了一张完整的测试保护网。任何一层出问题，都能在对应的测试层被快速定位，不需要一层一层去手工排查。这张网的另一个好处是测试用例之间有清晰的边界，新增功能的时候只需要考虑改动落在哪一层，相应地补对应层级的测试就好。
3.2 分层说明与执行优先级：哪些测试最值得先写
如果从零开始搭建这套体系，我的建议是从下往上写，按这个优先级来：
第一优先级是纯函数层。因为大部分纯函数不依赖外部环境，写起来最快、最稳定、执行的确定性最高。PocketPal AI里的Token估算函数、知识库切片函数、上下文压缩算法都属于这一层。这些函数一旦被写错，会导致上层所有模块连带出错，所以把它们覆盖全了，相当于给整个应用打了一个最可靠的地基。
第二优先级是状态管理层。状态管理是整个应用的中枢，消息状态、任务队列、模型切换状态全部汇聚在这里。如果状态管理有问题，UI层表现再正常也是假象。并且状态管理的Mock非常简单——只需要一个初始状态和一组action即可，不需要构造复杂的组件树。
第三优先级是组件层。组件层的价值在于防止UI回归，但它对Mock的要求也更高，需要模拟store、导航、事件回调等等。我的建议是组件测试不要追求全覆盖，集中覆盖用户交互最频繁的组件，比如输入框、发送按钮、消息气泡、会话列表。
第四优先级是流程集成测试。这类测试价值最高，但也最容易写坏。一个常见的坏味道是过度耦合内部实现，导致产品需求稍微调整一下，测试就大范围崩掉。我的经验是集成测试关注场景而不是实现，描述的是“用户在这个场景下期望得到什么结果”，而不是“函数A调用了函数B然后更新了状态C”。
4. 核心功能测试实践
4.1 纯函数与状态管理测试：给AI应用的地基加上保险
先说Token估算这个函数。PocketPal AI里的消息上下文有长度上限，超出上限时需要截断或者概览压缩。Token估算函数的输入是一条完整消息字符串和相关参数，输出是估算后的Token数量。这个函数看起来简单，但边界情况特别多——空字符串、超长文本、中英文混合、表情符号、代码片段等等。
我针对这个函数写的测试用例包含下面这些维度：
describe('estimateTokens', () => { test('空字符串返回0', () => { expect(estimateTokens('')).toBe(0); }); test('纯英文文本按字符数估算', () => { expect(estimateTokens('hello world')).toBeGreaterThan(0); }); test('中英文混合文本计算', () => { const chineseText = '你好，世界'; const mixedText = '你好，world'; expect(estimateTokens(mixedText)).toBeGreaterThan(estimateTokens(chineseText)); }); test('抛异常场景：输入非法参数', () => { expect(() => estimateTokens(null)).toThrow('Invalid input'); }); });对于状态管理的测试，我以消息发送流程为例。PocketPal AI的全局状态里有一个sendMessage的action，它会先把用户消息插入消息列表，然后创建一条空的助手待回复消息，接着调用推理引擎生成回复，最后把回复内容更新到待回复消息上。这个过程涉及三个状态变更阶段，我在测试里需要验证每个阶段的状态都正确。
describe('sendMessage flow', () => { test('发送消息后，消息列表更新且创建待回复消息', async () => { const store = configureMockStore(initialState); await store.dispatch(sendMessage('你好')); const state = store.getState(); expect(state.messages.length).toBe(initialState.messages.length + 1); expect(state.messages[state.messages.length - 1]).toMatchObject({ role: 'user', content: '你好' }); expect(state.pendingReply).toBe(true); }); });这种测试的价值在于，它明确地告诉每一个后来接手项目的人——“消息发送动作的预期行为是什么”。如果哪一天有同事不小心改了action逻辑，把用户消息插入动作和创建待回复消息的顺序调换了，这个测试立刻就能亮红灯。
4.2 组件交互测试：验证AI应用UI层的行为一致性
组件测试追求的目标不是“渲染出来长啥样”，而是“用户交互之后发生什么”。拿PocketPal AI的消息输入框组件来说，我需要验证的交互行为包括：输入内容时发送按钮是否可用、内容为空时发送按钮是否禁用、点击发送后是否触发预期的回调函数、连续快速发送时是否做了防抖处理。
用@testing-library/react-native写这类测试非常顺手，它提供的render和fireEvent可以模拟真实的用户操作，断言方式也更贴近行为：
import { render, fireEvent, waitFor } from '@testing-library/react-native'; import MessageComposer from '@/components/MessageComposer'; describe('MessageComposer', () => { test('输入内容后发送按钮变为可用状态', async () => { const mockSend = jest.fn(); const { getByPlaceholderText, getByTestId } = render( <MessageComposer onSend={mockSend} /> ); const input = getByPlaceholderText('输入消息...'); const sendButton = getByTestId('send-button'); expect(sendButton).toBeDisabled(); fireEvent.changeText(input, '你好，AI'); expect(sendButton).toBeEnabled(); fireEvent.press(sendButton); expect(mockSend).toHaveBeenCalledWith('你好，AI'); }); test('发送成功后输入框内容被清空', async () => { const { getByPlaceholderText, getByTestId } = render( <MessageComposer onSend={jest.fn()} /> ); const input = getByPlaceholderText('输入消息...'); fireEvent.changeText(input, '清空测试'); fireEvent.press(getByTestId('send-button')); await waitFor(() => { expect(input.props.value).toBe(''); }); }); });这里有一个实际踩过的坑值得分享。一开始我在组件测试里喜欢直接用render返回的queryByTestId去拿DOM节点，然后断言它的style属性。后来项目迭代了两次样式以后，这类测试崩溃了一大堆，没崩溃的那些也变成了纯装饰性测试，对功能回归毫无帮助。我现在的原则是——组件测试只测行为，不测样式。样式的正确性交给视觉回归测试（比如截图对比）去负责，组件测试全部聚焦在交互行为上。
4.3 集成测试与AI推理流程模拟：串联核心场景验证完整的链路
集成测试是整个测试方案中最具挑战性的部分，但它的回报也最高。PocketPal AI最核心的用户场景就是“对话”——用户发消息、AI生成回复、消息列表更新。这个链条涵盖了输入组件、状态管理、模型调度、推理引擎Mock、消息列表渲染等几乎所有核心模块。任何一个环节断裂，全链路都会出问题。
我的集成测试写法是这样的：先把全局状态、推理引擎Mock、组件渲染全部装配好，然后模拟完整的用户操作链路，最后对整个链路的结果进行断言。
describe('完整对话流程集成测试', () => { test('用户发送消息后收到AI回复并渲染', async () => { const fakeEngine = createFakeInferenceEngine({ response: '我是AI回复', delay: 100 }); const { getByPlaceholderText, getByTestId, getByText } = render( <ChatScreen inferenceEngine={fakeEngine} /> ); fireEvent.changeText(getByPlaceholderText('输入消息...'), '今天天气怎么样'); fireEvent.press(getByTestId('send-button')); await waitFor(() => { expect(getByText('今天天气怎么样')).toBeTruthy(); }); await waitFor(() => { expect(getByText('我是AI回复')).toBeTruthy(); }); expect(fakeEngine.generate).toHaveBeenCalled(); expect(fakeEngine.generate).toHaveBeenCalledTimes(1); }); test('推理失败时展示错误提示且消息列表不回滚', async () => { const fakeEngine = createFakeInferenceEngine({ error: new Error('model not loaded'), delay: 0 }); const { getByPlaceholderText, getByTestId, getByText } = render( <ChatScreen inferenceEngine={fakeEngine} /> ); fireEvent.changeText(getByPlaceholderText('输入消息...'), '触发错误'); fireEvent.press(getByTestId('send-button')); await waitFor(() => { expect(getByText('消息发送失败')).toBeTruthy(); }); expect(getByText('触发错误')).toBeTruthy(); }); });这里最关键的设计是fakeEngine。它不是Jest自动generate出来的Mock函数，而是一个专门写的手动模拟引擎。它可以配置返回内容、可注入错误、可控制耗时。它内部实现了一个真实的异步流程，让测试能“以假乱真”地验证整个应用的真实行为。
注意：集成测试一定要避免使用“固定等待时间”的写法，比如sleep(500)然后断言。这类测试在本地机器上可能稳定通过，但CI机器负载一高就变成随机飘红的常客。正确做法是利用jest的fake timers或waitFor来做时序控制。
5. 高级技巧与常见问题排查
5.1 异步时序控制：让测试不再受硬件性能影响
PocketPal AI的AI推理是高度异步的，模型加载、推理、返回结果之间的时序关系如果不做显式控制，测试结果就会受到硬件性能波动的影响。Jest的Fake Timers在这里可以发挥大作用，它能整体接管setTimeout、setInterval、Promise等异步API，让时序完全可控。
jest.useFakeTimers(); test('推理延迟回调触状态更新', async () => { const engine = new FakeInferenceEngine({ delay: 5000 }); const store = configureMockStore(initialState); store.dispatch(startInference('hello')); expect(store.getState().inferenceStatus).toBe('pending'); jest.advanceTimersByTime(2000); expect(store.getState().inferenceStatus).toBe('pending'); jest.advanceTimersByTime(3000); await Promise.resolve(); expect(store.getState().inferenceStatus).toBe('success'); expect(store.getState().messages).toContainEqual( expect.objectContaining({ role: 'assistant', content: 'mock reply' }) ); });在实际项目里，我遇到过很多“用真实定时器写了假同步代码”的情况——测试用例里写了个setTimeout(1000)，然后再用done回调去等。这类测试在本地开发机上可能能跑通，一旦上了CI，机器并发跑好几个任务，负载一高，1000毫秒根本不够用，于是测试开始随机失败。全量排查之后发现根本原因都是同一个——对时序没有做显式控制。所以我的经验是：涉及异步时序的测试，一律用Fake Timers显式控制，绝不依赖真实时间。
5.2 覆盖率统计与CI流程集成：让每一次提交都自动接受质量检验
覆盖率统计是衡量测试方案健康程度的重要指标。Jest本身集成了覆盖率统计能力，通过--coverage参数即可启动。但覆盖率统计跑全量的话会比较耗时，建议在提交前只跑单测，而把全量覆盖率放在夜间任务里执行。这样既能快速反馈，又不会因为覆盖率任务拖慢日常迭代节奏。
覆盖率之外，还需要重点关注两个指标——突变测试和分支覆盖。分支覆盖关注的是分支条件是否都被执行到。比如Token估算函数里的一个if-else分支，表达式是if (input.length > threshold)，那至少需要两个用例分别覆盖“长度大于阈值”和“长度小于等于阈值”的分支。我在istanbul和jest的配置里会加一个coverageThreshold的全局约束，要求全项目的lines覆盖不低于90%，branches不低于80%，达不到就fail。这个阈值一开始从60%逐步往上加，避免一开始就把团队逼得太紧。
在CI流程里，我把测试分成了三个阶段：
第一，本地快速检查。提交代码之前，在本机跑一遍目标目录的单测，确保基础用例通过。这一阶段要求轻快，不开覆盖率统计，保持秒级反馈。
第二，全量单测。代码合入主干分支之后，在CI上跑全量单测并开启覆盖率统计。这个阶段是质量门的核心，覆盖率不达标，构建直接失败，不让代码合入主线。
第三，集成测试专项。因为集成测试涉及跨模块联动，运行成本更高，单独抽出来在CI的另一个job里跑。这样即使集成测试跑挂了，也不会影响单测的快速反馈。
这样分阶段带来的好处是，测试反馈链路层次分明，问题能在最早阶段被发现，并且不同阶段的失败原因有明确的方向性，不用盲目去猜到底是哪一层出了问题。
5.3 常见问题排查实录：那些踩过的坑和解决办法
先列一个常见问题速查表，这些都是在PocketPal AI项目中实际遇到并解决的问题：
| 问题现象 | 可能的根因 | 解决方案 |
|---|---|---|
| 测试报“Cannot find module” | 路径别名未配置或模块不存在 | 配置moduleNameMapper，检查文件路径 |
| 测试报“Jest encountered an unexpected token” | 第三方库未转换 | 调整transformIgnorePatterns |
| 异步测试一直超时 | 使用了真实定时器等待长耗时操作 | 改用Fake Timers或waitFor |
| Mock函数没有被断言到 | Mock设置位置不对，或者测试间状态污染 | 确认在循环内调用jest.clearAllMocks() |
| 集成测试随机失败 | 事件回调顺序不稳定 | 将断言包在waitFor里，并保证test是异步的 |
| 覆盖率统计为0 | setup.js里mock覆盖了所有测试文件，导致代码未被加载 | 使用requireActual加载真实代码 |
除了速查表，我再展开讲一个最容易踩坑的问题——测试文件之间共享状态导致用例相互污染。PocketPal AI里有一个全局会话存储，最初我没在测试之间清理这个存储，导致一个测试跑完后，会话数据被带到了下一个测试里。这些数据会让许多断言失效，而且这种失效方式是间歇性的——单独运行某个文件时没问题，全量跑的时候就变得扑朔迷离。
解决办法是：在任何测试文件的顶部加上beforeEach(() => { localStorage.clear(); store.dispatch({ type: 'RESET_ALL' }); })，并且在setup.js里加上全局的清理逻辑。这看起来基础的不能再基础了，但它真的是很多团队上CI之后第一波夜间失败的头号元凶。
第二个印象很深的坑来自Mock的数据污染。PocketPal AI的模型推理引擎在测试环境里是一个单例对象，最开始因为Jest的模块缓存机制，同一个Mock函数的不同用例之间会共享调用记录。我一开始不知道要重置，结果出现了一个诡异的现象——用例A里调用了3次generate，用例B里只调用了1次，但断言却显示B的generate被调用了4次。后来在setup.js里做了统一清理，这类问题才彻底解决。
第三个值得说的是快照测试的合理使用。PocketPal AI的项目一开始大量使用快照测试，结果每次字段顺序调整或者样式微调，几十个快照同时失效，维护成本极高。后来我大幅压缩了快照测试的范围，只在最核心的组件上保留少量快照，并且把快照测试的定位从“验证功能正确性”改为“捕捉意外变更”。如果你想用快照测试，我建议同样是这个定位思路，别拿它当主力断言工具用。
5.4 从方案到习惯：测试维护的成本控制与长期价值
测试方案的构建是一回事，如何让整个团队长期维护好它，是另一回事。很多项目刚开始搭测试的时候轰轰烈烈，两三个月后测试就开始各种失真失修，最后沦为摆设。这里面最核心的问题通常是测试期望与产品行为脱节。
我的经验是要建立一个“测试即文档”的价值观。每写一个测试用例，不只是在“验证代码”，更是在“记录这个系统的行为规范”。当新产品需求进来的时候，先看测试里对现有行为的描述是否仍然正确，再改代码。这样测试成为了团队讨论需求时的一个参考基准，大家围绕它进行沟通和验收，而不是把它当成事后补交的作业。
另外一点很重要的是控制测试的脆弱性。引入组件测试和集成测试之后，测试维护成本天然就会高。稍微改一下UI文案，可能就有几十个测试要跟着改。这时候就要有取舍意识：不轻易写那些和UI文案强绑定的测试，会把文案提取成常量，测试里引用常量，而不是把文案本身写死。这样UI文案调整时，测试代码还稳稳地站在地上。
最后，我想分享一下这套方案在PocketPal AI项目中的长期数据表现。经过三个月的迭代维护，全量测试用例已经超过300个，从首次建立到现在的平均失败率维持在1%以下。这个成绩靠的不是“写特别多的测试”，而是“每个测试都准确地表达了系统的行为预期”，以及“对脆弱测试坚决说No”的维护纪律。只要这两点能坚持住，无论项目规模怎么增长，测试体系都能持续稳定地保护你的应用代码库。
我自己在实际维护这套测试方案的过程中，最深的感悟其实是——不要把Jest测试方案当成一次性工程去“搭建成型”，而是要把它当成和业务代码一起生长的活系统。每次新增功能都顺手补上对应的测试，每次测试失败都追到根因再修复。长期下来你会发现，这个测试套件已经成为项目中最可信的资产之一，它会一直为你的代码质量保驾护航。
