With @pinia/testing, how do you start a toast component test with three unread notifications and force the notifications store's unreadCount getter?

## Two ways to arrange a store for a component test A component test often needs the store in a particular state before mounting: three unread notifications, an empty list, a badge that should read `9+`. `@pinia/testing` gives two tools for this: - **`initialState`** for state: a per-store partial state applied when each store is created. - **Writable getters** for derived values: a test can assign a getter's value directly. Both avoid running actions, which with the default stubs would not run anyway. ## initialState ```ts createTestingPinia({ createSpy: vi.fn, initialState: { notifications: { items: [ { id: 'n1', text: 'Saved', level: 'info', read: false }, { id: 'n2', text: 'Retrying upload', level: 'warning', read: false }, { id: 'n3', text: 'Sync failed', level: 'error', read: false }, ], }, }, }) ``` How it is applied: 1. The key is the **store id**, the string passed as the first argument of `defineStore()`. A key that matches no id is silently ignored. 2. When the store is created, its normal initial state is built first, from `state()` or the setup function's refs. 3. Then the testing pinia **merges** the entry into `store.$state`. Nested plain objects are merged key by key; arrays, `Date` values and other non-plain values are **replaced**. 4. The object configures every store on that pinia, so one `initialState` can seed several stores at once. Because it is a merge, you only write the fields the test cares about. Seeding after mounting with `store.$patch()` also works, but the component may already have rendered and run effects with the default state; `initialState` avoids that first render. ## Writable getters A getter is normally read-only: it is a cached computed value derived from state. Inside a testing pinia, getters become writable: ```ts const store = useNotificationsStore() store.unreadCount = 9 ``` - The forced value **sticks**: changing `items` does not recompute `unreadCount` while it is overridden. - Other getters that read `unreadCount` see the forced value. - Assigning **`undefined`** restores the original getter, which recomputes from state. - It works for option-store getters and for `computed()` in setup stores. - Getters are typed as read-only properties, so TypeScript usually needs a cast or an expected-error comment on the assignment. | Need | Tool | Scope | |---|---|---| | component starts with specific data | `initialState` | applied at store creation | | derived value hard to reach through data | assign the getter | from the assignment until reset | | change state during the test | `store.items = ...` or `store.$patch(...)` | immediate | ## Seeding several stores at once The toast component may read more than one store, for example a settings store that decides whether toasts auto-hide. `initialState` covers them all in one object: ```ts initialState: { notifications: { items: [/* three notices */] }, settings: { autoHideMs: 0 }, } ``` Each entry is applied when its store is created, whether the component or the test creates it first. That also makes cross-store getters testable: if `unreadCount` ignored muted levels read from the settings store, seeding both stores exercises the real combination, while forcing `unreadCount` would skip it. Two details are easy to miss: 1. `initialState` is read when a store is **created**. A store that already exists on that pinia does not pick up later changes to the object. 2. State written by `initialState` goes through the store's normal state, so a setup store's returned refs receive the values and its getters recompute from them. ## Which to prefer Prefer **state** when it is easy to build: three notices in `initialState` exercise both the component and the real `unreadCount` getter. Force the **getter** when building the state is laborious or irrelevant, for example the `9+` overflow rendering, or a getter that combines other stores. Overriding everything turns the test into a test of the template only. ## Common mistakes - Keying `initialState` by the composable name instead of the store id. - Expecting an array in `initialState` to be appended to the default array; it replaces it. - Forgetting that a forced getter ignores later state changes, then asserting a recomputed value. - Assigning getters on a regular pinia and expecting it to work outside tests.