Mocking composables and stores in Vue - Deep Dive

Overview - Mocking composables and stores

What is it?

Mocking composables and stores means creating fake versions of Vue composables and state stores during testing. This helps isolate parts of your app to test them without relying on real data or side effects. It allows you to simulate behaviors and control outputs for predictable tests. This is especially useful in Vue 3 apps using the Composition API and state management libraries like Pinia.

Why it matters

Without mocking, tests would depend on real data and external states, making them slow, flaky, or hard to control. Mocking lets you test components and logic in isolation, ensuring bugs are caught early and fixes are reliable. It saves time and frustration by avoiding unpredictable test results caused by real store changes or network calls.

Where it fits

Before learning mocking, you should understand Vue 3 basics, the Composition API, and how composables and stores work. After mastering mocking, you can explore advanced testing techniques, integration tests, and end-to-end testing frameworks.

Mental Model

Core Idea

Mocking composables and stores means replacing real reactive logic with controlled fake versions to test components in isolation.

Think of it like...

It's like using a flight simulator instead of a real airplane to practice flying safely without risks or unpredictable conditions.

┌───────────────┐       ┌───────────────┐
│ Real Composable│──────▶│ Real Store    │
└──────┬────────┘       └──────┬────────┘
       │                       │
       ▼                       ▼
┌───────────────┐       ┌───────────────┐
│ Mock Composable│──────▶│ Mock Store   │
└───────────────┘       └───────────────┘

Component uses composable/store
  │
  ▼
Test replaces real with mock
  │
  ▼
Controlled, predictable behavior

Build-Up - 7 Steps

1

Foundation

Understanding Vue Composables

Concept: Learn what composables are and how they provide reusable reactive logic in Vue 3.

Composables are functions that use Vue's Composition API to share reactive state and behavior. For example, a composable might return a reactive counter and functions to change it. Components call composables to get this logic.

Result

You know how composables package reactive logic for reuse.

Understanding composables is key because mocking means replacing these reusable logic units with fakes.

2

Foundation

Basics of Vue Stores

Concept: Learn what stores are and how they manage shared state in Vue apps.

Stores like Pinia hold global reactive state and methods to update it. Components and composables can access stores to share data across the app. Stores are reactive and trigger updates when state changes.

Result

You understand how stores centralize app state.

Knowing stores helps because mocking often targets these shared state containers to isolate tests.

3

Intermediate

Why Mock Composables and Stores

🤔Before reading on: do you think tests should use real stores or fake ones? Commit to your answer.

Concept: Introduce the reasons for mocking to isolate tests and control behavior.

Using real composables or stores in tests can cause unpredictable results due to shared state or side effects like API calls. Mocking replaces them with controlled versions that return fixed data or simulate behavior, making tests reliable and fast.

Result

You see why mocking improves test quality and speed.

Understanding the need for mocking prevents flaky tests and helps design better test suites.

4

Intermediate

Mocking a Composable Function

🤔Before reading on: do you think you can mock a composable by simply replacing its import? Commit to your answer.

Concept: Learn how to replace a composable with a mock version in tests.

In your test file, you can mock a composable by using tools like Jest's jest.mock() to replace the import with a fake function. The mock returns controlled reactive data or functions. This isolates the component from the real composable logic.

Result

Tests run with the mock composable, producing predictable outputs.

Knowing how to mock composables lets you test components without running real logic or side effects.

5

Intermediate

Mocking Pinia Stores in Tests

🤔Before reading on: do you think you must create a full store instance to mock it, or can you fake parts? Commit to your answer.

Concept: Learn how to mock Pinia stores by creating fake store instances or mocking store methods.

You can create a mock Pinia store by using createTestingPinia() from @pinia/testing or by manually mocking store methods and state. This lets you control store state and actions during tests without affecting real stores.

Result

Tests use the mock store, isolating component behavior from real app state.

Understanding store mocking techniques helps you write focused tests that avoid shared state issues.

6

Advanced

Handling Reactive Data in Mocks

🤔Before reading on: do you think mocks should return plain values or reactive ones? Commit to your answer.

Concept: Learn why mocks must return reactive data to keep Vue reactivity working in tests.

Mocks should return reactive objects (like ref or reactive) to simulate real composables or stores. Returning plain values breaks reactivity and can cause tests to miss updates or behave differently than in real use.

Result

Tests correctly react to state changes in mocks, matching real app behavior.

Knowing to keep reactivity in mocks ensures tests reflect real component behavior and catch reactive bugs.

7

Expert

Pitfalls of Over-Mocking and Solutions

🤔Before reading on: do you think mocking everything always improves tests? Commit to your answer.

Concept: Explore when mocking too much can hide bugs and how to balance mocks with real logic.

Over-mocking can make tests pass but miss integration bugs because mocks don't behave exactly like real composables or stores. Experts balance mocks with integration tests and use partial mocks or spies to verify real behavior while controlling side effects.

Result

Tests remain reliable and meaningful, catching real issues without false confidence.

Understanding the limits of mocking helps maintain test quality and avoid blind spots in your app.

Under the Hood

Vue composables and stores use reactive proxies internally to track dependencies and trigger updates. When mocking, the test replaces these reactive objects or functions with fakes that mimic the reactive interface. The testing framework intercepts imports or store creation to inject mocks, allowing control over reactive state and methods without running real logic or side effects.

Why designed this way?

Vue's Composition API and stores are designed for modular, reactive logic reuse. Mocking fits naturally by swapping these modular units during tests. This design allows isolation without changing app code. Alternatives like global state replacement or manual stubbing are less flexible and more error-prone.

┌─────────────────────┐
│ Component           │
│ uses composable/store│
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Import intercepted   │
│ by test framework   │
└─────────┬───────────┘
          │
          ▼
┌─────────────────────┐
│ Mock composable/store│
│ returns reactive data│
└─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think mocking a composable means rewriting its entire logic? Commit yes or no.

Common Belief: Mocking means rewriting the whole composable or store logic from scratch.

Reality: Mocking usually means replacing the composable or store with a simple fake that returns controlled reactive data or functions, not rewriting full logic.

Why it matters: Trying to rewrite full logic wastes time and can introduce errors, defeating the purpose of fast, isolated tests.

Quick: Do you think mocks can be plain objects without reactivity? Commit yes or no.

Common Belief: Mocks can be plain objects or values since tests only check outputs.

Reality: Mocks must use Vue's reactive APIs (ref, reactive) to keep component reactivity working in tests.

Why it matters: Using plain mocks breaks reactivity, causing tests to miss updates and behave differently than the real app.

Quick: Do you think mocking everything always makes tests better? Commit yes or no.

Common Belief: More mocking always improves test reliability and speed.

Reality: Over-mocking can hide integration bugs and give false confidence; some real logic should be tested.

Why it matters: Blindly mocking everything can cause bugs to slip into production unnoticed.

Quick: Do you think mocking stores means you can't test real store behavior? Commit yes or no.

Common Belief: Mocking stores means you never test real store logic or state changes.

Reality: You can combine mocks with integration tests or partial mocks to test real store behavior alongside controlled tests.

Why it matters: Believing this limits test strategies and reduces test coverage of important app logic.

Expert Zone

1

Mocking composables that return functions requires careful handling to preserve function identity and reactivity, or tests may fail unexpectedly.

2

Using createTestingPinia() allows automatic mocking of stores with spies on actions, enabling verification of calls without manual mocks.

3

Partial mocks let you mock only some parts of a composable or store, preserving real behavior elsewhere, which balances isolation and realism.

When NOT to use

Mocking is not ideal for end-to-end tests or full integration tests where real composables and stores must interact naturally. In those cases, use real instances and test the full app flow.

Production Patterns

In production, developers use mocking in unit tests for components and composables, combined with integration tests using real stores. They also use spy functions to verify store actions and composable calls, ensuring both isolation and correctness.

Connections

Dependency Injection

Mocking composables and stores is a form of dependency injection where dependencies are replaced with controlled versions.

Understanding dependency injection helps grasp how mocking swaps real dependencies for fakes to isolate tests.

Test Doubles in Software Testing

Mocking composables and stores is a specific case of using test doubles like mocks and stubs.

Knowing test double types clarifies when to use mocks, stubs, or spies for different testing needs.

Simulators in Aviation Training

Mocking is like simulators that replicate real systems for safe practice.

This cross-domain link shows how controlled environments help learn and test without real-world risks.

Common Pitfalls

#1 Returning plain objects instead of reactive refs in mocks.

Wrong approach:

jest.mock('./useCounter', () => ({ count: 0, increment: () => {} }))

Correct approach:

import { ref } from 'vue';
jest.mock('./useCounter', () => ({ count: ref(0), increment: () => {} }))

Root cause:

Misunderstanding that Vue reactivity requires reactive wrappers like ref or reactive.

#2 Mocking the entire store when only one action needs control.

Wrong approach:

jest.mock('@/stores/userStore', () => ({ state: {}, actions: {} }))

Correct approach:

import { setActivePinia, createPinia } from 'pinia';
setActivePinia(createPinia());
const userStore = useUserStore();
jest.spyOn(userStore, 'login').mockImplementation(() => Promise.resolve());

Root cause:

Not knowing partial mocks or spying techniques to mock selectively.

#3 Mocking composables globally without resetting between tests.

Wrong approach:

jest.mock('./useData'); // no reset or cleanup

Correct approach:

beforeEach(() => { jest.resetModules(); jest.clearAllMocks(); });
jest.mock('./useData');

Root cause:

Forgetting test isolation causes mocks to leak and tests to interfere.

Key Takeaways

Mocking composables and stores means replacing real reactive logic with controlled fakes to isolate tests.

Mocks must preserve Vue reactivity by returning reactive refs or reactive objects to keep tests accurate.

Over-mocking can hide bugs; balance mocks with real logic and integration tests for best coverage.

Tools like Jest and Pinia's testing utilities simplify mocking and spying on composables and stores.

Understanding mocking deeply improves test reliability, speed, and developer confidence in Vue 3 apps.