How do you test a Svelte component updates a writable store?

WHAT THIS TESTS: This question probes whether you understand the boundary between component internals and external state in Svelte, and how Testing Library wants you to interact with that boundary. The interviewer cares if you know that a writable store is a reactive primitive that lives outside the component tree, and that testing it requires treating the store as an external dependency rather than something owned by the component instance. It also checks if you know the Svelte Testing Library specific quirk that fireEvent is async and must be awaited so that Svelte has time to flush reactive updates before you assert.

A GOOD ANSWER COVERS: First, explain that the test should import both the component and the store if the store is defined at the module level, or alternatively instantiate a fresh writable store and pass it in as a prop if the component accepts it. Second, render the component with @testing-library/svelte and use a screen query to find the interactive element. Third, await the interaction because Svelte Testing Library exports an async fireEvent that wraps updates in act; for example, await fireEvent.click(screen.getByRole('button')). Fourth, assert on the store value using Svelte's get function from the store module or by subscribing briefly, since the store is the actual contract under test. Fifth, acknowledge that while Testing Library generally prefers DOM assertions, directly checking the store is appropriate when the store is shared state consumed by other parts of the application.

COMMON WRONG ANSWERS: A major red flag is reaching into the rendered component instance to pull out state, such as using result.component.$set or internal variables, because that breaks the Testing Library principle of testing the same way a user interacts with the app. Another mistake is treating fireEvent as synchronous, writing fireEvent.click without await, which causes a race condition where the assertion runs before Svelte commits the reactive update. A third anti-pattern is asserting only on the DOM when the question explicitly asks about the store, or conversely ignoring the DOM entirely and testing implementation details that have no user-facing effect.

LIKELY FOLLOW-UPS: The interviewer might ask how you would test a derived store that depends on the writable store, in which case you would subscribe to the derived store and assert its computed value after the interaction. They could also ask what you would do if the store update triggered an async side effect like a fetch, leading you to discuss waiting for elements to appear with findBy queries or using waitFor. Another follow-up is how to reset store state between tests, which is best handled by creating a fresh store instance per test or mocking the module.

ONE CONCRETE EXAMPLE: Suppose you have a counter store exported from stores.js and a Counter.svelte component that imports it and displays a button to increment. In your test file, import { render, screen, fireEvent } from '@testing-library/svelte', import Counter from './Counter.svelte', and import { counter, increment } from './stores.js'. Render the component with render(Counter). Then write await fireEvent.click(screen.getByText('Increment')). Finally, assert with expect(get(counter)).toBe(1). This sequence respects the async boundary, uses DOM interaction, and validates the external store contract.