Vitest on recca0120 Tech Notes

Shared HTTP Mocks Across a Monorepo: When Fakes Aren't the Right Tool

Mon, 20 Apr 2026 07:45:00 +0800

The previous posts covered DI + Fake + in-memory and sharing Fakes across a monorepo. That approach has one scope limit: services you own.

When the dependency is an external HTTP API (Stripe, GitHub, third-party SaaS), Fake isn’t the right tool. This post covers how to apply the same “share across layers” philosophy to HTTP mocks instead.

Why External HTTP Doesn’t Fit the Fake Pattern

The FakeUserService from the last post works because:

You own UserService’s interface and implementation
You know its behavioral invariants
The Fake shares the same interface as production

External HTTP APIs fail all three conditions:

The “interface” is someone else’s REST/GraphQL endpoint — out of your control
Behavior changes without warning
Production uses fetch + network; you can’t swap in a Fake class

Forcing a Fake becomes a maintenance nightmare: Stripe changes its response shape, FakeStripeService doesn’t follow, tests stay green while production breaks.

The Right Substitution Point: The Network Layer

For external HTTP, substitution happens at the HTTP call itself, not at some service interface. Intercept fetch / http.request and return fake responses.

That’s what MSW / msw-fetch-mock do:

Production code is unchanged (still calls fetch(...))
Tests intercept network requests and return the fake response you define
After tests, things return to normal

Compared to Fakes:

	Fake (internal)	HTTP mock (external)
Substitution point	interface	network layer
Needs DI	yes	no
Test setup	inject the Fake	start a mock server
Production changes	interface can change	`fetch` calls unchanged

Frontend and backend both call external APIs. Both need HTTP mocking.

Common wrong approach:

Frontend uses vi.spyOn(global, 'fetch')

1
2
3


vi.spyOn(global, 'fetch').mockResolvedValue(
 new Response(JSON.stringify({ data: 'fake' }))
);

Backend uses nock

1

nock('https://api.stripe.com').get('/v1/customers').reply(200, { data: 'fake' });

Two different APIs, two different behaviors — same external API, two mock implementations. As much of a mess as mock proliferation.

Same philosophy as Fakes — put HTTP mock handlers in a shared package, and every layer’s tests import the same set.

MSW supports this natively:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// shared/testing/stripe-handlers.ts
import { http, HttpResponse } from 'msw';

export const stripeHandlers = [
 http.get('https://api.stripe.com/v1/customers/:id', ({ params }) => {
 return HttpResponse.json({
 id: params.id,
 name: 'Test Customer',
 email: 'test@example.com',
 });
 }),

 http.post('https://api.stripe.com/v1/customers', async ({ request }) => {
 const body = await request.json();
 return HttpResponse.json({ id: 'cus_123', ...body }, { status: 201 });
 }),
];

This handler set feeds both frontend and backend tests.

Backend Usage

Node.js uses setupServer:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// server/src/__tests__/billing.test.ts
import { setupServer } from 'msw/node';
import { stripeHandlers } from '@app/shared/testing';

const server = setupServer(...stripeHandlers);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test('creates customer via Stripe API', async () => {
 const billing = new BillingService();
 const customer = await billing.createCustomer({ name: 'Alice' });

 expect(customer.id).toBe('cus_123');
});

The fetch('https://api.stripe.com/...') inside BillingService is transparently intercepted by MSW. Production code needs zero test-aware changes.

Frontend Usage

Browser environments use Service Worker — but Vitest also works fine with the Node version:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// client/src/__tests__/checkout.test.tsx
import { setupServer } from 'msw/node';
import { stripeHandlers } from '@app/shared/testing';

const server = setupServer(...stripeHandlers);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test('shows customer name after creation', async () => {
 render(<CheckoutForm />);
 fireEvent.click(screen.getByText('Create'));

 expect(await screen.findByText('Test Customer')).toBeInTheDocument();
});

Same stripeHandlers, works on both sides.

Customizing Responses: Testing Edge Cases

The shared handlers cover the happy path. Special cases get layered on with server.use():

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


import { http, HttpResponse } from 'msw';

test('handles Stripe API error', async () => {
 server.use(
 http.post('https://api.stripe.com/v1/customers', () => {
 return HttpResponse.json(
 { error: { message: 'Card declined' } },
 { status: 402 }
 );
 })
 );

 const billing = new BillingService();
 await expect(billing.createCustomer({ name: 'Bob' })).rejects.toThrow('Card declined');
});

server.use() is temporary — resetHandlers() returns to the shared handlers.

MSW’s API Too Verbose? Try msw-fetch-mock

MSW’s native API writes one handler per endpoint, which can be verbose in tests. If you want features like times(n), persist(), assertNoPendingInterceptors(), use msw-fetch-mock — it sits on top of MSW with an API aligned to undici MockAgent and Cloudflare Workers fetchMock:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import { fetchMock } from 'msw-fetch-mock';

beforeAll(() => fetchMock.activate({ onUnhandledRequest: 'error' }));
afterAll(() => fetchMock.deactivate());
afterEach(() => {
 fetchMock.assertNoPendingInterceptors();
 fetchMock.reset();
});

test('creates customer', async () => {
 fetchMock.get('https://api.stripe.com')
 .intercept({ path: '/v1/customers', method: 'POST' })
 .reply(201, { id: 'cus_123' });

 const billing = new BillingService();
 const customer = await billing.createCustomer({ name: 'Alice' });

 expect(customer.id).toBe('cus_123');
});

Full API reference and comparison with other mocking libraries in the earlier msw-fetch-mock overview.

Fakes and HTTP mocks solve two sides of the same problem:

Fakes share: interface + in-memory implementation Frontend and backend both import the FakeUserService class, plug it into a constructor.

HTTP mocks share: request handler lists Frontend and backend both import the stripeHandlers array, feed it to an MSW server.

One can’t replace the other:

Forcing HTTP mocks on internal services adds unnecessary network — production is a direct function call, why wrap it in HTTP just to mock
Forcing Fakes on external APIs reimplements someone else’s service by hand — behavior can never stay in sync

You need both.

The Complete Monorepo Testing Strategy

Combining all three posts, a mature monorepo testing architecture looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


packages/
 └── shared/
 └── testing/
 ├── fakes/ # Fakes for internal services
 │ ├── fake-user-service.ts
 │ └── fake-storage-service.ts
 ├── http-handlers/ # MSW handlers for external APIs
 │ ├── stripe-handlers.ts
 │ └── github-handlers.ts
 └── index.ts

Internal services → Fakes (previous two posts)
External HTTP APIs → MSW handlers (this post)
Every layer imports what it needs

Tests look consistent across layers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import { FakeUserService } from '@app/shared/testing';
import { stripeHandlers } from '@app/shared/testing';
import { setupServer } from 'msw/node';

const server = setupServer(...stripeHandlers);

beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

test('creates user and customer', async () => {
 const userService = new FakeUserService();
 const service = new SignupService(userService);

 await service.signup({ name: 'Alice' });

 expect(await userService.get(1)).toBeDefined(); // internal: Fake state
 // Stripe call is intercepted by MSW and returns fake data (external HTTP)
});

When Neither Applies

A few rare cases neither fits:

Real API integration tests (contract testing, verifying Stripe’s actual behavior) — don’t mock, use the sandbox environment
Pure function testing (no external dependencies) — just pass arguments

The rule: mocks/fakes isolate “things not under test.” They’re not an excuse to hide dependencies.

Summary

The complete test-double strategy for a monorepo:

Dependency type	Tool	Shared location
Internal service (stateful)	Fake	`shared/testing/fakes/`
Internal service (pure functions)	Stub	inside the package
External HTTP API	MSW handlers	`shared/testing/http-handlers/`
Real contract verification	Don’t mock — use sandbox	N/A

The central claim of this three-post series: test doubles should be shared infrastructure across layers, not boilerplate re-written in every file. Fake and MSW answer at different layers, but the thinking is the same — write once, share, test behavior not implementation.

References

Shared Fakes Across a Monorepo: One Test Double from Frontend to Backend

Mon, 20 Apr 2026 07:30:00 +0800

The previous post covered DI + Fake + in-memory basics. This one takes it further, into a scenario most testing tutorials ignore: how frontend, backend, and shared logic can use the same Fake in a monorepo.

📝 Note

Scope of this post: internal services — classes you wrote, with interfaces you can swap. If the dependency is an external HTTP API (Stripe, GitHub, third-party SaaS), Fake isn’t the right tool. See part three on shared HTTP mocks for that case.

The common approach is for the frontend to have its mocks, the backend its fixtures, and each package does its own thing. The result: the same service is mocked twice or three times, often with inconsistent behavior — the frontend test assumes null, the backend mock returns an empty array, and the bug only shows up at integration time.

The Problem: Duplicated Mocks

Say a monorepo looks like this:

1
2
3
4
5


packages/
 ├── shared/ # shared TypeScript types
 ├── client/ # React frontend
 ├── server/ # API backend
 └── domain/ # business logic / data access

Client calls server APIs, server calls domain services, domain hits the database. All four packages need tests.

Each package writing its own mock:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// client/__tests__/user-list.test.tsx
const mockApi = {
 fetchUsers: vi.fn().mockResolvedValue([{ id: 1, name: 'Alice' }]),
};

// server/__tests__/users-route.test.ts
const mockUserService = {
 list: vi.fn().mockReturnValue([{ id: 1, name: 'Alice' }]),
};

// domain/__tests__/user-service.test.ts
const mockDb = {
 query: vi.fn().mockResolvedValue([{ id: 1, name: 'Alice' }]),
};

Three layers, three copies, all describing “there’s a user named Alice.” Any change to the data shape means updating three places — and it’s easy to miss one.

Solution: Put the Fake in the Lowest Shared Package

The Fake belongs in the lowest-level shared package, so every package that needs it can import from the same source.

1
2
3
4
5
6
7
8
9


packages/
 ├── shared/
 │ ├── src/
 │ │ ├── types.ts # shared types
 │ │ └── interfaces.ts # service interfaces
 │ └── testing/ # shared test utilities
 │ ├── fake-user-service.ts
 │ ├── fake-storage-service.ts
 │ └── index.ts

Or extract a dedicated test-utils package for this. The key is that every package imports the same copy.

Writing a Shared FakeUserService

Start from the bottom — the interface:

1
2
3
4
5
6
7


// shared/src/interfaces.ts
export interface UserService {
 list(): Promise<User[]>;
 get(id: number): Promise<User | null>;
 create(user: Omit<User, 'id'>): Promise<User>;
 delete(id: number): Promise<void>;
}

And the Fake:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


// shared/testing/fake-user-service.ts
export class FakeUserService implements UserService {
 private users = new Map<number, User>();
 private nextId = 1;

 async list(): Promise<User[]> {
 return Array.from(this.users.values());
 }

 async get(id: number): Promise<User | null> {
 return this.users.get(id) ?? null;
 }

 async create(user: Omit<User, 'id'>): Promise<User> {
 const created = { ...user, id: this.nextId++ };
 this.users.set(created.id, created);
 return created;
 }

 async delete(id: number): Promise<void> {
 this.users.delete(id);
 }

 // test-only helpers
 seed(users: User[]): void {
 users.forEach((u) => this.users.set(u.id, u));
 const maxId = Math.max(...users.map((u) => u.id), 0);
 this.nextId = maxId + 1;
 }

 reset(): void {
 this.users.clear();
 this.nextId = 1;
 }
}

This Fake is about to be used by all three packages.

Backend: Testing an API Route

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


// server/src/users-route.ts
export function createUsersRoute(userService: UserService) {
 const router = new Router();

 router.get('/users', async (ctx) => {
 ctx.body = await userService.list();
 });

 router.post('/users', async (ctx) => {
 ctx.body = await userService.create(ctx.request.body);
 });

 return router;
}

Test:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// server/src/__tests__/users-route.test.ts
import { FakeUserService } from '@app/shared/testing';

test('GET /users returns all users', async () => {
 const userService = new FakeUserService();
 userService.seed([
 { id: 1, name: 'Alice' },
 { id: 2, name: 'Bob' },
 ]);

 const app = createApp(createUsersRoute(userService));
 const res = await request(app).get('/users');

 expect(res.body).toHaveLength(2);
});

test('POST /users creates a new user', async () => {
 const userService = new FakeUserService();

 const app = createApp(createUsersRoute(userService));
 await request(app).post('/users').send({ name: 'Charlie' });

 expect(await userService.get(1)).toEqual({ id: 1, name: 'Charlie' });
});

Using a full Fake makes the test read naturally: seed data → call the API → verify the Fake’s final state. No mockResolvedValue, no toHaveBeenCalledWith.

Frontend: Testing a React Component

The frontend uses the exact same FakeUserService:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// client/src/user-list.tsx
export function UserList({ service }: { service: UserService }) {
 const [users, setUsers] = useState<User[]>([]);

 useEffect(() => {
 service.list().then(setUsers);
 }, [service]);

 return (
 <ul>
 {users.map((u) => (
 <li key={u.id}>{u.name}</li>
 ))}
 </ul>
 );
}

Test:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// client/src/__tests__/user-list.test.tsx
import { FakeUserService } from '@app/shared/testing';

test('renders list of users', async () => {
 const service = new FakeUserService();
 service.seed([
 { id: 1, name: 'Alice' },
 { id: 2, name: 'Bob' },
 ]);

 render(<UserList service={service} />);

 expect(await screen.findByText('Alice')).toBeInTheDocument();
 expect(screen.getByText('Bob')).toBeInTheDocument();
});

Identical seed API, identical behavior guarantees. Frontend and backend tests work with the same mental model.

Business Logic: Composing Fakes

Domain services often depend on multiple Fakes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// domain/src/order-service.ts
export class OrderService {
 constructor(
 private userService: UserService,
 private storage: StorageService,
 ) {}

 async createOrder(userId: number, items: Item[]) {
 const user = await this.userService.get(userId);
 if (!user) throw new Error('User not found');

 const order = { id: Date.now(), userId, items };
 this.storage.set(`order:${order.id}`, order);
 return order;
 }
}

The test composes the two Fakes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


test('creates order for existing user', async () => {
 const userService = new FakeUserService();
 const storage = new FakeStorageService();
 userService.seed([{ id: 1, name: 'Alice' }]);

 const orderService = new OrderService(userService, storage);
 const order = await orderService.createOrder(1, [{ sku: 'A', qty: 1 }]);

 expect(storage.get(`order:${order.id}`)).toEqual(order);
});

test('throws when user does not exist', async () => {
 const userService = new FakeUserService();
 const storage = new FakeStorageService();

 const orderService = new OrderService(userService, storage);

 await expect(orderService.createOrder(999, [])).rejects.toThrow('User not found');
});

Two Fakes snap together like Lego. The only difference from production is that the dependencies are Fake implementations.

What This Pattern Gets You

1. Behavioral consistency

All three layers share one Fake, so behavior is guaranteed consistent. The frontend assumes “delete then get returns null” and the backend test uses the same behavior — no more “frontend mock returns null, backend mock returns undefined” drift.

2. Lower maintenance cost

Change the interface once, update the Fake once, and all three layers of tests pick up the new behavior automatically. No hunting for scattered mocks.

3. Fakes are living documentation

New team members want to know how UserService behaves? Reading FakeUserService is more useful than a pure interface — it has actual state transition logic.

4. Integration tests fall out easily

Need integration tests where client talks directly to server? Chain the Fakes together, no mock hierarchy redesign required.

The prerequisite for sharing a Fake is that the dependency is that layer’s public interface. Internal details of a single layer don’t belong in a shared package:

HTTP middleware unique to the server → internal stubs are fine
Context used only by one React hook → internal fixture
Low-level database driver details → keep in domain

Rule of thumb: dependencies used by at least two packages get a shared Fake. Dependencies unique to one package stay put.

Still Test the Fake Itself

Following on from the previous post: once a Fake lives in a shared package, testing it matters even more. Three layers depend on it — a bug pollutes the whole test foundation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// shared/testing/__tests__/fake-user-service.test.ts
describe('FakeUserService', () => {
 test('create assigns incrementing ids', async () => {
 const service = new FakeUserService();
 const a = await service.create({ name: 'Alice' });
 const b = await service.create({ name: 'Bob' });
 expect(a.id).toBe(1);
 expect(b.id).toBe(2);
 });

 test('seed respects existing ids for nextId', async () => {
 const service = new FakeUserService();
 service.seed([{ id: 5, name: 'Old' }]);
 const next = await service.create({ name: 'New' });
 expect(next.id).toBe(6);
 });

 test('delete removes user', async () => {
 const service = new FakeUserService();
 service.seed([{ id: 1, name: 'Alice' }]);
 await service.delete(1);
 expect(await service.get(1)).toBeNull();
 });
});

These tests document the Fake’s complete behavioral contract. Every client, server, and domain test rests on these validated invariants.

Summary

The counterintuitive takeaway for monorepo testing: don’t let each package write its own mocks. Lift Fakes to the shared layer.

The full workflow:

Define interfaces in the shared package
Put Fake implementations there too (testing/ or a dedicated test-utils)
Frontend, backend, and business logic all import the same copy
Write tests for the Fake’s own invariants
Compose Fakes to test complex service layers

Testing starts to feel like building with Lego — interfaces are connectors, Fakes are reusable blocks, and frontend and backend tests follow the same principle.

When the dependency is an external HTTP API (Stripe, GitHub, etc.), Fakes aren’t the right tool — you need network-level interception instead. That’s the subject of the next post: sharing HTTP mocks across a monorepo.

References

DI + Fake + in-memory: Writing Frontend Tests That Survive Refactors

Mon, 20 Apr 2026 07:00:00 +0800

The most common testing pattern I see looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


test('saves user data', () => {
 const mockStorage = {
 set: vi.fn(),
 get: vi.fn().mockReturnValue(null),
 };
 const service = new UserService(mockStorage);

 service.save({ id: 1, name: 'Alice' });

 expect(mockStorage.set).toHaveBeenCalledWith('user:1', { id: 1, name: 'Alice' });
});

Looks fine. Tests pass. But this approach has a long-term problem: tests are coupled to implementation details. The day UserService switches from set to setItem, or wraps a namespace around the key, the test breaks. Every internal change requires a test change.

Fake + in-memory sidesteps these traps. This post walks through how three concepts fit together: DI (architecture) + Fake (pattern) + in-memory (implementation technique).

First: Why DI Matters

Dependency Injection’s core idea is “don’t new dependencies inside a class.” The connection to testing is straightforward: it lets you swap implementations.

Without DI:

1
2
3
4
5


class UserService {
 save(user: User) {
 localStorage.setItem(`user:${user.id}`, JSON.stringify(user));
 }
}

No way to swap out localStorage during tests — you end up spying on globals or using vi.stubGlobal. Ugly, and tests bleed state between each other.

With DI:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


interface StorageService {
 set(key: string, value: unknown): void;
 get(key: string): unknown;
}

class UserService {
 constructor(private storage: StorageService) {}

 save(user: User) {
 this.storage.set(`user:${user.id}`, user);
 }
}

Now localStorage can be replaced with anything during tests — including the Fake we’re about to build.

No framework required. Constructor injection is enough. Frontend frameworks (React, Vue) achieve the same thing via context or providers.

The Problem with Mocks

The biggest issue with mocks is that each test has to assemble its own. Adding a “get should return a value” scenario to the test above:

1
2
3
4
5
6
7


const mockStorage = {
 set: vi.fn(),
 get: vi.fn().mockImplementation((key) => {
 if (key === 'user:1') return JSON.stringify({ id: 1, name: 'Alice' });
 return null;
 }),
};

Mocks don’t know that get should return what was just set — they have no state. Every test has to manually configure the interaction order and return values.

Worse, assertions hook into calls: expect(mock.set).toHaveBeenCalledWith(...). You’re verifying “which internal method got called” instead of “what observable outcome was produced.” Touch the implementation, break the test.

What a Fake Is

A Fake is a real implementation — just a simplified one. It implements the same interface as production, but stores data and runs logic in memory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class FakeStorageService implements StorageService {
 private store = new Map<string, unknown>();

 set(key: string, value: unknown): void {
 this.store.set(key, value);
 }

 get(key: string): unknown {
 return this.store.get(key) ?? null;
 }

 // test-friendly helpers
 has(key: string): boolean {
 return this.store.has(key);
 }

 reset(): void {
 this.store.clear();
 }
}

Key differences from a mock:

Has state: what you set is what you get back
Predictable: behaves like production, not made up per-test
Reusable: one copy for the whole project, not hand-assembled per test

Rewriting the Test with a Fake

1
2
3
4
5
6
7
8


test('saves user data', () => {
 const storage = new FakeStorageService();
 const service = new UserService(storage);

 service.save({ id: 1, name: 'Alice' });

 expect(storage.get('user:1')).toEqual({ id: 1, name: 'Alice' });
});

Differences:

No expect(...).toHaveBeenCalledWith(...) — we assert the thing actually exists in storage
We test behavior (stored data can be retrieved), not implementation (the set method was called)
If UserService switches to setItem internally or wraps keys in a namespace, the test survives as long as the interface doesn’t change

Building a Good In-Memory Fake

A few design points that matter:

1. Implement the production interface

Most important rule. A Fake must share the same interface as the production implementation:

1
2


class FakeStorageService implements StorageService { ... }
class LocalStorageService implements StorageService { ... }

This guarantees test and runtime behavior align. A Fake without a shared interface is a pretend — you’re testing a system you imagined, not the one you built.

2. Provide test-only setup methods

Fakes can add methods production doesn’t need, for arranging state:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


class FakeStorageService implements StorageService {
 // production interface
 set(key: string, value: unknown) { ... }
 get(key: string) { ... }

 // test-only helpers
 seed(entries: Record<string, unknown>) {
 Object.entries(entries).forEach(([k, v]) => this.store.set(k, v));
 }

 throwOnNextSet(error: Error) {
 this.nextError = error;
 }
}

These keep the arrange step clean:

1
2
3
4
5
6
7


test('loads existing user', () => {
 const storage = new FakeStorageService();
 storage.seed({ 'user:1': { id: 1, name: 'Alice' } });

 const service = new UserService(storage);
 expect(service.load(1)).toEqual({ id: 1, name: 'Alice' });
});

3. Have a reset method

Tests must be isolated. Provide reset() so each test starts clean:

1
2
3


beforeEach(() => {
 storage.reset();
});

Or create a fresh instance per test. The latter is cleaner — you can’t forget to reset something that doesn’t exist.

💡 Tip

If your test framework rebuilds the instance in beforeEach, prefer that — forgetting to call reset() is an invisible bug, rebuilding the instance makes that class of bug impossible.

The Fake Itself Needs Tests

Something most people never consider: the Fake’s behavior must be tested.

The Fake stands in for production across your entire test suite. If the Fake misbehaves, every test built on top of it rests on a false foundation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


describe('FakeStorageService', () => {
 test('get returns what was set', () => {
 const storage = new FakeStorageService();
 storage.set('foo', 'bar');
 expect(storage.get('foo')).toBe('bar');
 });

 test('get returns null for missing key', () => {
 const storage = new FakeStorageService();
 expect(storage.get('missing')).toBeNull();
 });

 test('reset clears all data', () => {
 const storage = new FakeStorageService();
 storage.set('foo', 'bar');
 storage.reset();
 expect(storage.get('foo')).toBeNull();
 });
});

The value of these tests: they describe the Fake’s invariants. With those written down, reusing the Fake elsewhere is safe — its behavior is known.

When to Use Fake vs Stub

Fake isn’t always the right tool. Some cases are a better fit for Stub (pure input/output).

Use a Fake when

The dependency has state (storage, cache, database, session)
The dependency’s behavior needs to stay consistent across tests
Multiple tests share this dependency
You need to verify “what went in can come out” style interactions

Use a Stub when

The dependency is purely “input → output”
Only a few tests need it
Different tests need very different return values
A full Fake isn’t worth building (e.g. complex external API responses)

Most projects mix both: shared services get a Fake, one-off external dependencies get a stub.

Summary

The full flow:

Write production code with DI — inject dependencies via constructor, never new them inside
Define interfaces — both production and test doubles implement the same one
Write the Fake — in-memory implementation with seed/reset helpers
Test the Fake — verify its own invariants
Test production code — use the Fake as a stand-in, assert behavior not method calls

This combo gives tests three long-term wins: not coupled to implementation details, clean cross-test state, and a trustworthy Fake validated on its own.

The next post covers how a single Fake can power tests from the frontend down through the backend in a monorepo — where this pattern really shines.

Series continuation

Shared Fakes across a monorepo — one Fake from frontend to backend
Shared HTTP mocks across a monorepo — MSW for external APIs
Why AI agents need good tests even more — how this pattern helps Claude Code

Vitest on recca0120 Tech Notes

Shared HTTP Mocks Across a Monorepo: When Fakes Aren't the Right Tool

Why External HTTP Doesn’t Fit the Fake Pattern

The Right Substitution Point: The Network Layer

The Sharing Challenge

The Fix: Share the Same Handler Set

Backend Usage

Frontend Usage

Customizing Responses: Testing Edge Cases

MSW’s API Too Verbose? Try msw-fetch-mock

Why the Sharing Pattern Differs

The Complete Monorepo Testing Strategy

When Neither Applies

Summary

References

Shared Fakes Across a Monorepo: One Test Double from Frontend to Backend

The Problem: Duplicated Mocks

Solution: Put the Fake in the Lowest Shared Package

Writing a Shared FakeUserService

Backend: Testing an API Route

Frontend: Testing a React Component

Business Logic: Composing Fakes

What This Pattern Gets You

When Not to Share Fakes

Still Test the Fake Itself

Summary

References

DI + Fake + in-memory: Writing Frontend Tests That Survive Refactors

First: Why DI Matters

The Problem with Mocks

What a Fake Is

Rewriting the Test with a Fake

Building a Good In-Memory Fake

The Fake Itself Needs Tests

When to Use Fake vs Stub

Summary

Series continuation

References