Mocking composables and stores in Vue - Mini Project: Build & Apply

Mocking composables and stores in Vue

📖 Scenario: You are building a Vue 3 application that uses composables and Pinia stores to manage state and logic. To ensure your components work correctly, you want to write tests that mock these composables and stores.This project will guide you step-by-step to create a mock composable and a mock Pinia store, then use them in a test setup.

🎯 Goal: Build a Vue test setup that mocks a composable called useUser and a Pinia store called useCartStore. You will create the mock data, configure mock implementations, apply the mocks in a test, and finalize the test setup.

📋 What You'll Learn

Create a mock user object with specific properties

Create a mock cart store with an items property and an action

Mock the useUser composable to return the mock user

Mock the useCartStore Pinia store to use the mock store

Use the mocks in a test setup for a Vue component

💡 Why This Matters

🌍 Real World

In real Vue projects, mocking composables and stores allows developers to write focused tests that do not depend on actual backend data or complex state logic. This makes tests faster and more reliable.

💼 Career

Understanding how to mock composables and stores is important for frontend developers working with Vue and Pinia, especially when writing unit and integration tests for components.

1

Create mock user data

Create a constant called mockUser with an object containing these exact properties: id set to 1, name set to 'Alice', and isLoggedIn set to true.

Vue

# Create a constant mockUser with id 1, name 'Alice', and isLoggedIn true
# Your code here

Hint

Use const mockUser = { id: 1, name: 'Alice', isLoggedIn: true } to create the mock user object.

2

Create mock cart store

Create a constant called mockCartStore with an object that has items set to an empty array, and an addItem method that is a jest mock function.

Vue

const mockUser = { id: 1, name: 'Alice', isLoggedIn: true }
# Create a constant mockCartStore with items: [] and addItem mock function
# Your code here

Hint

Use jest.fn() to create a mock function for addItem.

3

Mock composable and store imports

Use jest.mock to mock the useUser composable module to return mockUser, and mock the useCartStore Pinia store module to return mockCartStore.

Vue

const mockUser = { id: 1, name: 'Alice', isLoggedIn: true }
const mockCartStore = {
  items: [],
  addItem: jest.fn()
}
# Mock useUser composable and useCartStore Pinia store
# Your code here

Hint

Use jest.mock('module', () => ({ functionName: () => mockData })) pattern to mock modules.

4

Use mocks in test setup

Import mount from @vue/test-utils and a component called MyComponent. Then create a test block named 'renders with mocked composable and store' that mounts MyComponent and asserts the component exists.

Vue

const mockUser = { id: 1, name: 'Alice', isLoggedIn: true }
const mockCartStore = {
  items: [],
  addItem: jest.fn()
}

jest.mock('@/composables/useUser', () => ({
  useUser: () => mockUser
}))

jest.mock('@/stores/cart', () => ({
  useCartStore: () => mockCartStore
}))

# Import mount and MyComponent, then write a test that mounts MyComponent and checks it exists
# Your code here

Hint

Use mount to render the component and expect(wrapper.exists()).toBe(true) to check it rendered.

Practice

1. What is the main reason to mock composables or stores in Vue component tests?

easy

A. To automatically generate UI snapshots

B. To improve the component's runtime performance

C. To isolate the component test from real logic and external dependencies

D. To enable two-way data binding in tests

Solution

1. Step 1: Understand the purpose of mocking

   Mocking replaces real implementations with fake ones to isolate tests from external logic.

2. Step 2: Apply this to composables and stores

   Mocking composables and stores prevents side effects and focuses tests on the component itself.

3. Final Answer:

   To isolate the component test from real logic and external dependencies -> Option C

4. Quick Check:

   Mocking isolates tests = A [OK]

Hint: Mock to isolate component logic from external code [OK]

Common Mistakes:

• Thinking mocking improves runtime performance
• Confusing mocking with UI snapshot generation
• Believing mocking enables data binding

2. Which syntax correctly mocks a composable module named useAuth using Vitest's vi.mock()?

easy

A. vi.mock('./useAuth', () => ({ useAuth: () => ({ isLoggedIn: true }) }))

B. vi.mock('useAuth', () => ({ isLoggedIn: true }))

C. vi.mock('useAuth', () => ({ useAuth: () => ({ isLoggedIn: true }) }))

D. vi.mock('./useAuth', () => ({ isLoggedIn: true }))

Solution

1. Step 1: Identify the module path

   Modules are mocked by their relative or absolute path, so './useAuth' is correct if the file is local.

2. Step 2: Provide a factory returning the mocked composable function

   The factory must return an object with the composable function that returns the mocked state.

3. Final Answer:

   vi.mock('./useAuth', () => ({ useAuth: () => ({ isLoggedIn: true }) })) -> Option A

4. Quick Check:

   Correct path and factory function = C [OK]

Hint: Mock with correct path and return a function for composables [OK]

Common Mistakes:

• Using module name without path when path is required
• Returning state object directly instead of a function
• Mocking without a factory function

3. Given this mocked store code snippet:

vi.mock('./store', () => ({ useStore: () => ({ count: 5, increment: vi.fn() }) }))

const store = useStore();
store.increment();
console.log(store.count);

What will be logged to the console?

medium

A. undefined

B. 5

C. Error: increment is not a function

D. 0

Solution

1. Step 1: Analyze the mocked store return values

   The mocked useStore returns an object with count: 5 and increment as a mock function.

2. Step 2: Check the console.log output

   The count property is 5 and is not changed by calling increment() because it's a mock function without implementation.

3. Final Answer:

   5 -> Option B

4. Quick Check:

   Mocked count value logged = 5 [OK]

Hint: Mocked state stays same unless mock function changes it [OK]

Common Mistakes:

• Assuming mock function changes state automatically
• Expecting undefined because increment is mocked
• Confusing mock function with real implementation

4. Identify the error in this test mocking a composable:

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

medium

A. The mock should return a function, not an object directly

B. The vi.fn() should be replaced with a real function

C. The module path './useCounter' is incorrect

D. The mock should not include the increment function

Solution

1. Step 1: Understand composable mocking pattern

   Composable modules export functions, so mocks must return a function, not an object.

2. Step 2: Identify the incorrect mock structure

   The code returns an object directly instead of a function returning the object.

3. Final Answer:

   The mock should return a function, not an object directly -> Option A

4. Quick Check:

   Composable mocks return functions = D [OK]

Hint: Mock composables as functions returning objects [OK]

Common Mistakes:

• Returning object directly instead of function
• Replacing vi.fn() unnecessarily
• Incorrect module path assumptions

5. You want to test a Vue component that uses a Pinia store with a fetchData action. How do you mock the store to verify fetchData is called without running its real logic?

hard

A. Replace fetchData with an empty async function in the real store

B. Import the real store and spy on fetchData without mocking

C. Mock the component instead of the store

D. Use vi.mock() to replace the store module with a mock where fetchData is a vi.fn()

Solution

1. Step 1: Understand mocking for store actions

   To isolate tests, replace the store module with a mock that has fetchData as a mock function.

2. Step 2: Use vi.mock() to replace the store module

   This allows you to track calls to fetchData without executing its real code.

3. Final Answer:

   Use vi.mock() to replace the store module with a mock where fetchData is a vi.fn() -> Option D

4. Quick Check:

   Mock store action with vi.fn() = A [OK]

Hint: Mock store actions with vi.fn() to track calls without side effects [OK]

Common Mistakes:

• Not mocking the store and calling real logic
• Mocking the component instead of the store
• Replacing functions with empty but untracked implementations