Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Die API in React-Tests mocken

Die API in React-Tests mocken

~16 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026

Kapitel 95 testete NUR die Formular-INTERAKTION – SOBALD ein Test das ERGEBNIS einer Mutation prüfen soll, braucht es eine MOCK-API, statt GEGEN das ECHTE Backend zu laufen.

Mock Service Worker installieren

npm install --save-dev msw

MSW fängt axios-Requests auf NETZWERK-Ebene ab (statt axios SELBST zu mocken) – der PRODUKTIONSCODE (apiClient aus Kapitel 74) bleibt UNVERÄNDERT, GENAU der Ansatz, der Tests am NÄCHSTEN am ECHTEN Verhalten hält.

Handler definieren

src/mocks/handlers.ts
import { http, HttpResponse } from 'msw';

export const handlers = [
  http.post('*/projects', async ({ request }) => {
    const body = (await request.json()) as { name: string };

    return HttpResponse.json(
      { '@id': '/api/projects/999', id: 999, name: body.name },
      { status: 201 },
    );
  }),
];
src/mocks/server.ts
import { setupServer } from 'msw/node';
import { handlers } from './handlers';

export const server = setupServer(...handlers);

Den Server im Test-Setup aktivieren

src/test-setup.ts
import '@testing-library/jest-dom';
import { beforeAll, afterEach, afterAll } from 'vitest';
import { server } from './mocks/server';

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

resetHandlers() NACH JEDEM Test ist WICHTIG: OHNE diesen Reset könnte ein Test-SPEZIFISCHER Handler (z. B. für einen simulierten Fehlerfall) VERSEHENTLICH einen NACHFOLGENDEN Test BEEINFLUSSEN.

Einen vollständigen Mutation-Test

it('leert das Formular nach erfolgreichem Erstellen', async () => {
  const user = userEvent.setup();
  renderWithQueryClient(<CreateProjectForm />);

  const input = screen.getByPlaceholderText('Projektname');
  await user.type(input, 'Test-Projekt');
  await user.click(screen.getByRole('button', { name: /projekt erstellen/i }));

  await waitFor(() => expect(input).toHaveValue(''));
});

waitFor ist NOTWENDIG, da der Mutation-Aufruf ASYNCHRON ist – der Test WARTET, BIS die Bedingung ZUTRIFFT, statt SOFORT (und damit ZU FRÜH) zu prüfen.

Einen Fehlerfall simulieren

it('zeigt eine Fehlermeldung bei einem Validierungsfehler', async () => {
  server.use(
    http.post('*/projects', () =>
      HttpResponse.json(
        { violations: [{ propertyPath: 'name', message: 'Zu kurz.' }] },
        { status: 422 },
      ),
    ),
  );

  // ... Formular ausfüllen und absenden, dann prüfen:
  expect(await screen.findByText('Zu kurz.')).toBeInTheDocument();
});

server.use() ÜBERSCHREIBT den STANDARD-Handler NUR für DIESEN EINEN Test – GENAU der violations-Mechanismus aus Kapitel 79 wird HIER AUTOMATISIERT geprüft, statt MANUELL im Browser.

Tipp: MSW-Handler LASSEN SICH auch für die Browser-DevTools während der Entwicklung wiederverwenden ("MSW im Browser") – NÜTZLICH, um das Frontend OHNE laufendes Backend zu entwickeln, EIN Thema jenseits DIESER Schulung, aber ERWÄHNENSWERT für WEITERFÜHRENDE Recherche.