单元测试中模拟 Pinia Store 状态应使用 createTestingPinia 配置 initialState 直接注入预设数据，覆盖 store 默认 state 工厂函数，支持 Option/Setup Store，无需触发 action 即可验证 getters 等逻辑。
在单元测试中模拟 Pinia Store 的状态，核心是使用 @pinia/testing 提供的 createTestingPinia 创建一个专用于测试的 Pinia 实例，并通过 initialState 配置项直接注入预设状态。这比手动调用 action 或 patch 更可靠、更隔离。
用 createTestingPinia 预设初始状态
这是最常用也最推荐的方式。你不需要运行任何 action，就能让 store 一初始化就拥有指定的 state 值。
-
initialState接收一个对象，键为 store ID，值为该 store 的完整初始 state - 它会覆盖 store 自身定义的
state: () => ({})工厂函数，直接使用你传入的数据 - 适用于 Option Store 和 Setup Store，无需额外处理
示例：
const pinia = createTestingPinia({initialState: {
counter: { count: 100 },
user: { name: 'test-user', role: 'admin' }
}
});
配合 defineStore 在测试中直接构造 Store 实例
如果你只测某个 store 的逻辑（比如 getters 或纯 action），可以跳过组件挂载，直接创建 store 实例并传入 mock 状态。
- 用
createPinia()+setActivePinia()激活实例 - 调用 store factory 函数（如
useCounterStore()）时，store 会自动从当前 active Pinia 中读取配置 - 搭配
initialState即可让这个 store 实例一创建就带数据
避免依赖真实 action 触发来“准备”状态
很多初学者习惯先 mount 组件、再点击按钮、再等待 action 执行完才断言——这属于集成测试范畴，且容易因副作用失败。单元测试应聚焦“给定状态，输出是否符合预期”。
- 例如测试 getter
doubleCount，直接让count = 5，断言store.doubleCount === 10 - 不要为了测 getter 而先调用
increment()；那是在测 action 和 state 更新链路，不是 getter 本身 - 若必须验证 action 行为，用
stubActions: false关闭默认打桩，再用jest.spyOn控制行为
注意 Setup Store 的状态结构一致性
Setup Store 返回的是响应式引用（ref、computed），但 initialState 仍需传 plain object —— createTestingPinia 内部会自动将其转为响应式并赋值。
- 例如 setup store 定义了
const count = ref(0)，initialState 里写{ count: 42 }即可 - 嵌套对象（如
user.profile）也按普通 JS 对象结构填写，无需手动reactive - 不支持传入
ref或computed，否则可能丢失响应性或报错
