Monorepo 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.

Monorepo 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