DEV Community

Cover image for Was ist nock? HTTP-Anfragen in Node.js mocken (inkl. No-Code-Alternative)
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

Was ist nock? HTTP-Anfragen in Node.js mocken (inkl. No-Code-Alternative)

Wenn Node.js-Tests fehlschlagen, weil eine Drittanbieter-API nicht erreichbar, langsam oder ratenbegrenzt ist, testen Sie nicht mehr nur Ihren Code, sondern eine externe Abhängigkeit. Für stabile Unittests sollten Sie die HTTP-Schicht mocken. In Node.js ist nock dafür eines der Standardwerkzeuge: Es fängt ausgehende HTTP(S)-Requests ab und liefert definierte Antworten zurück. Dieser Leitfaden zeigt, wie Sie nock praktisch einsetzen und wann ein gemeinsamer Mock-Server besser passt als In-Process-Mocking.

Apidog noch heute ausprobieren

Was ist nock?

nock ist eine Node.js-Bibliothek zum Mocken von HTTP-Servern und zum Definieren von Request-Erwartungen. Sie überschreibt zur Laufzeit die nativen http- und https-Module von Node.js. Dadurch kann nock ausgehende Requests abfangen, bevor sie das Netzwerk erreichen.

Das ist besonders nützlich für Unittests:

  • keine echten API-Aufrufe
  • keine Wartezeit durch langsame externe Services
  • keine Rate-Limits
  • keine Testfehler durch fremde Systeme
  • deterministische Antworten für Erfolgs- und Fehlerfälle

Sie definieren im Test zum Beispiel:

Wenn mein Code GET https://api.example.com/users/42 aufruft, antworte mit Status 200 und diesem JSON-Body.

nock funktioniert in Node.js mit Clients, die auf http/https aufbauen, darunter fetch, axios, got und node-fetch. Installieren Sie es als Entwicklungsabhängigkeit:

npm install --save-dev nock
Enter fullscreen mode Exit fullscreen mode

Ein kleines nock-Beispiel

Angenommen, Ihre Anwendung ruft einen Benutzer von einer externen API ab:

// user-service.js
export async function getUser(id) {
  const res = await fetch(`https://api.example.com/users/${id}`);

  if (!res.ok) {
    throw new Error(`Request failed: ${res.status}`);
  }

  return res.json();
}
Enter fullscreen mode Exit fullscreen mode

Der passende Test mit nock sieht so aus:

// user-service.test.js
import nock from 'nock';
import { getUser } from './user-service.js';

test('returns the user when the API responds', async () => {
  nock('https://api.example.com')
    .get('/users/42')
    .reply(200, { id: 42, name: 'Ada Lovelace' });

  const user = await getUser(42);

  expect(user).toEqual({ id: 42, name: 'Ada Lovelace' });
});
Enter fullscreen mode Exit fullscreen mode

Die wichtigsten Teile:

nock('https://api.example.com')
Enter fullscreen mode Exit fullscreen mode

legt den Host fest.

.get('/users/42')
Enter fullscreen mode Exit fullscreen mode

definiert Methode und Pfad.

.reply(200, { id: 42, name: 'Ada Lovelace' })
Enter fullscreen mode Exit fullscreen mode

definiert Statuscode und Response-Body.

Wenn getUser(42) ausgeführt wird, verlässt kein Request den Prozess. nock liefert stattdessen die konfigurierte Antwort zurück.

Fehlerfälle mit nock testen

Der größte Nutzen von Mocking zeigt sich oft bei Fehlerpfaden. Eine echte API können Sie nicht zuverlässig dazu bringen, genau jetzt einen 500-Fehler zu liefern. Mit nock ist das eine Zeile:

test('throws when the API returns 500', async () => {
  nock('https://api.example.com')
    .get('/users/99')
    .reply(500);

  await expect(getUser(99)).rejects.toThrow('Request failed: 500');
});
Enter fullscreen mode Exit fullscreen mode

So testen Sie gezielt:

  • 500 Internal Server Error
  • 404 Not Found
  • Timeouts
  • ungültige Response-Bodies
  • leere Antworten
  • Rate-Limit-Szenarien

Wenn Sie speziell Serverfehler simulieren möchten, geht dieser Leitfaden zum Mocken einer 500 Internal Server Error Response tiefer ins Detail.

Nützliche nock-Funktionen für Tests

Interceptor mehrfach verwenden

Standardmäßig wird ein nock-Interceptor nach einem erfolgreichen Match entfernt. Wenn derselbe Endpunkt mehrfach aufgerufen wird, verwenden Sie .persist():

nock('https://api.example.com')
  .persist()
  .get('/health')
  .reply(200, { status: 'ok' });
Enter fullscreen mode Exit fullscreen mode

Exakte Anzahl von Aufrufen erwarten

Mit .times(n) begrenzen Sie, wie oft ein Mock verwendet werden darf:

nock('https://api.example.com')
  .get('/users/42')
  .times(2)
  .reply(200, { id: 42 });
Enter fullscreen mode Exit fullscreen mode

Langsame Antworten simulieren

Mit .delay(ms) testen Sie Timeout-Handling:

nock('https://api.example.com')
  .get('/slow-endpoint')
  .delay(3000)
  .reply(200, { ok: true });
Enter fullscreen mode Exit fullscreen mode

Dynamische Pfade matchen

Wenn IDs oder Pfade variieren, können Sie reguläre Ausdrücke verwenden:

nock('https://api.example.com')
  .get(/\/users\/\d+/)
  .reply(200, { id: 123, name: 'Test User' });
Enter fullscreen mode Exit fullscreen mode

Mocks zwischen Tests aufräumen

Verhindern Sie, dass Mocks aus einem Test in den nächsten laufen:

import nock from 'nock';

afterEach(() => {
  nock.cleanAll();
});
Enter fullscreen mode Exit fullscreen mode

Sicherstellen, dass erwartete Requests wirklich passiert sind

Eine gute Testgewohnheit: Prüfen Sie, ob alle definierten Interceptors verwendet wurden.

test('calls the expected endpoint', async () => {
  const scope = nock('https://api.example.com')
    .get('/users/42')
    .reply(200, { id: 42 });

  await getUser(42);

  scope.done();
});
Enter fullscreen mode Exit fullscreen mode

Wenn der Request nie ausgelöst wurde, schlägt der Test fehl. Alternativ können Sie global prüfen:

expect(nock.isDone()).toBe(true);
Enter fullscreen mode Exit fullscreen mode

Wo nock nicht mehr das richtige Werkzeug ist

nock ist für eine klare Aufgabe gebaut: HTTP-Requests innerhalb eines einzelnen Node.js-Testprozesses abfangen.

Das funktioniert sehr gut für Unittests. Es funktioniert aber nicht, wenn der Mock außerhalb dieses Prozesses erreichbar sein muss.

Typische Grenzen:

  • Ein Frontend im Browser kann Ihr nock-Setup nicht direkt verwenden.
  • Eine Mobile-App im Simulator kann keinen nock-Mock aufrufen.
  • QA kann keine manuellen Tests gegen nock ausführen.
  • Eine Postman-Collection kann nock nicht erreichen.
  • Andere Teams in anderen Repositories können Ihre Test-Mocks nicht wiederverwenden.

nock-Mocks leben in Ihrer Testdatei, in Ihrer Node.js-Laufzeit und nur für die Dauer des Testprozesses.

Sobald Sie eine Fake-API benötigen, die über eine echte URL erreichbar ist, brauchen Sie einen Mock-Server.

Typische Anwendungsfälle:

  • Das Frontend entwickelt gegen Endpunkte, bevor das Backend fertig ist.
  • Mehrere Teams brauchen dieselben Beispielantworten.
  • Eine Integration soll ohne Live-Backend demonstriert werden.
  • QA möchte Grenzfälle manuell testen.
  • Externe Clients sollen gegen einen stabilen API-Vertrag entwickeln.

Für diese Abwägung helfen die Artikel Mock-Server vs. echter Server und API-Mocking.

nock vs. gehosteter Mock-Server mit Apidog

nock und ein gehosteter Mock-Server lösen unterschiedliche Probleme.

nock ist ideal für In-Code-Interception in Node.js-Unittests. Ein Tool wie Apidog stellt dagegen einen gemeinsam nutzbaren, schema-gesteuerten Mock-Server bereit, der über eine echte URL erreichbar ist.

Viele Teams verwenden beides:

  • nock für schnelle Unit-Tests
  • Apidog-Mock-Server für Frontend, QA, Integrationen und teamübergreifende Entwicklung

Apidog Mock-Server

Apidog generiert einen Mock-Server direkt aus Ihrem API-Design. Sie definieren Endpunkte und Schemas, und Apidog liefert Antworten unter einer Live-URL. Die Mock-Daten können auf Feldnamen und Typen basieren, sodass Clients realistischere Antworten erhalten als bei statischen Platzhaltern.

nock Apidog Mock-Server
Wo es läuft Im Node.js-Testprozess Gehosteter Server mit echter URL
Am besten geeignet für Unittests, Fehlersimulation Integration, manuelles Testen, teamübergreifende Arbeit
Wer kann es erreichen Code im selben Prozess Jeder Client mit der URL
Einrichtung Code in jeder Testdatei Generiert aus dem API-Schema
Sprachen Nur Node.js Jeder Client, jede Sprache
Mock-Daten Sie schreiben jede Antwort selbst Mock aus Schema und Feldnamen
Teilen Nicht direkt teilbar Im Team teilbar

Wichtig: Apidog ersetzt nock nicht in Jest- oder Mocha-Unittests. Wenn Sie einen einzelnen fetch-Aufruf im Test abfangen und das Verhalten Ihrer Funktion prüfen möchten, ist nock weiterhin passend.

Apidog wird relevant, wenn der Mock eine Adresse braucht, die andere Personen, Tools oder Plattformen erreichen können. Einen praktischen Einstieg finden Sie im Leitfaden zum Mocken einer API für Tests. Sie können außerdem Apidog herunterladen und aus einer bestehenden OpenAPI-Datei einen Mock erstellen.

Andere Alternativen zu nock

nock ist nicht die einzige Option. Die richtige Wahl hängt davon ab, wo Ihr Code läuft und welche Ebene Sie testen möchten.

MSW

MSW (Mock Service Worker) fängt Requests auf Netzwerkebene ab. Im Browser nutzt es einen Service Worker, in Node.js einen Interceptor. Dadurch können dieselben Mock-Definitionen in Browser- und Node-Umgebungen funktionieren.

Die offizielle MSW-Dokumentation erklärt das Modell im Detail.

Jest Manual Mocks

Mit Jest können Sie Module wie axios direkt ersetzen:

jest.mock('axios');
Enter fullscreen mode Exit fullscreen mode

Das ist für kleine Tests oft schnell eingerichtet, bindet den Test aber stärker an einen konkreten HTTP-Client. Wenn Sie später von axios zu fetch wechseln, müssen Sie die Tests anpassen. Das Jest Mocking Tutorial behandelt dieses Muster.

Test-Doubles und Stubs

Sie können auch die Funktion stubben, die den HTTP-Aufruf ausführt, zum Beispiel mit Sinon oder mit den Bordmitteln Ihres Test-Runners. Das ist nützlich, wenn Sie bewusst nicht auf HTTP-Ebene testen möchten. Sie verlieren dabei aber das Request-Matching von nock.

Die Kernfrage lautet:

Testen Sie Logik innerhalb eines Prozesses oder brauchen Sie eine Fake-API im Netzwerk?

Für den ersten Fall passen nock, MSW oder Stubs. Für den zweiten Fall brauchen Sie einen Mock-Server.

Häufig gestellte Fragen

Ist nock kostenlos?

Ja. nock ist Open Source unter der MIT-Lizenz und kann kostenlos über npm installiert werden. Sie verwenden es typischerweise als Entwicklungsabhängigkeit in Ihrer Testsuite.

Funktioniert nock mit fetch und axios?

Ja. nock fängt auf der http-/https-Schicht von Node.js ab. Deshalb funktioniert es mit Clients, die darauf aufbauen, darunter natives fetch, axios, got und node-fetch.

Kann ich nock im Browser verwenden?

Nein. nock ist nur für Node.js, weil es die HTTP-Module von Node.js patcht. Diese Module existieren im Browser nicht.

Für Browser-Mocking verwenden Sie zum Beispiel MSW oder richten Ihr Frontend auf einen gehosteten Mock-Server aus. Dieser Überblick zu Mock-APIs in JavaScript erklärt die Optionen.

Was ist der Unterschied zwischen nock und einem Mock-Server?

nock fängt Requests innerhalb Ihres Node.js-Testprozesses ab und öffnet keinen echten Netzwerkport.

Ein Mock-Server läuft unter einer echten URL und kann von Browsern, Mobile-Apps, Testtools, QA und anderen Teams aufgerufen werden.

Kurz gesagt:

  • Verwenden Sie nock für Node.js-Unittests.
  • Verwenden Sie einen Mock-Server, wenn mehrere Clients dieselben Fake-Antworten erreichen müssen.

Zusammenfassung

nock ist eine zuverlässige Wahl für HTTP-Mocking in Node.js-Unittests. Es fängt ausgehende Requests im Prozess ab, liefert definierte Antworten zurück und macht Tests schneller, stabiler und deterministischer. Besonders wertvoll ist es für Fehlerfälle, die sich gegen echte APIs nur schwer reproduzieren lassen.

Wenn der Mock außerhalb Ihrer Testdatei erreichbar sein muss, verwenden Sie stattdessen einen gemeinsam genutzten Mock-Server. Apidog generiert einen Mock aus Ihrem API-Schema und stellt ihn unter einer Live-URL bereit. So können Frontend, QA und andere Teams auf Basis desselben API-Vertrags entwickeln, bevor das Backend fertig ist.

Apidog herunterladen und eine OpenAPI-Spezifikation in einen funktionierenden Mock umwandeln.

Top comments (0)