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

Wenn Ihre Node.js-Tests fehlschlagen, weil eine Drittanbieter-API nicht erreichbar, langsam oder ratenbegrenzt ist, haben Sie kein Codeproblem. Sie haben ein Abhängigkeitsproblem. Die Lösung besteht darin, die HTTP-Schicht zu mocken, damit Ihre Unittests jedes Mal auf die gleiche Weise ablaufen, und nock ist das npm-Paket, zu dem die meisten Node-Entwickler greifen. Dieser Leitfaden erklärt, was nock ist, zeigt ein kleines funktionierendes Beispiel und behandelt, wo ein gemeinsamer Mock-Server besser passt als die In-Process-Interzeption. Für die vollständige Bibliotheksreferenz ist das nock GitHub Repo die Quelle der Wahrheit.

Was ist nock?

nock ist eine Bibliothek zum Mocken und für Erwartungen an HTTP-Server für Node.js. Es funktioniert, indem es die http- und https-Module von Node zur Laufzeit überschreibt, sodass jede ausgehende Anfrage, die Ihr Code sendet, abgefangen und mit einer vorgefertigten Antwort beantwortet werden kann. Nichts verlässt Ihre Maschine. Der Netzwerkaufruf findet nie statt.

Das ist wichtig für Unittests. Wenn Sie eine Funktion testen, die eine externe API aufruft, möchten Sie den echten Dienst nicht erreichen. Echte Aufrufe sind langsam, kosten Geld, können aus Gründen fehlschlagen, die nichts mit Ihrem Code zu tun haben, und machen Ihre Testsuite nicht-deterministisch. nock ermöglicht es Ihnen zu sagen: „Wenn mein Code eine GET-Anfrage an diese URL sendet, gib dieses exakte JSON mit diesem Statuscode zurück.“ Ihr Test überprüft dann, wie Ihre Funktion diese Antwort verarbeitet.

nock ist nur für Node.js. Es greift in den nativen HTTP-Stack ein, daher funktioniert es mit fetch, axios, got, node-fetch und allem anderen, was auf http/https aufbaut. Es hat Millionen von wöchentlichen Downloads und ist seit Jahren eine Standardwahl für Backend-Tests. Sie installieren es als Entwicklungsabhängigkeit, da es nur in Tests und niemals in der Produktion läuft.

Ein kleines nock-Beispiel

Angenommen, Sie haben eine Funktion, die einen Benutzer von einer API abruft. Hier ist die Funktion:

// 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();
}

Hier ist nun ein Test, der nock verwendet, um die Anfrage abzufangen:

// 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' });
});

Lesen Sie es von oben nach unten. nock('https://api.example.com') legt den Host fest, den Sie abfangen möchten. .get('/users/42') gleicht die Methode und den Pfad ab. .reply(200, {...}) definiert den Status und den zurückzugebenden Body. Wenn getUser(42) ausgeführt wird, wird der echte Netzwerkaufruf ausgetauscht und stattdessen Ihre vorgefertigte Antwort zurückgegeben.

Sie können Fehler auf die gleiche Weise mocken, was der Teil ist, den Leute vergessen zu testen:

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');
});

Das Testen des „unhappy path“ ist der Punkt, an dem Mocking seinen Wert beweist. Sie können eine Live-API nicht zuverlässig dazu bringen, auf Anfrage einen 500er-Fehler zurückzugeben, aber Sie können einen in einer einzigen Zeile fälschen. Wenn die Fehlersimulation Ihr Hauptziel ist, geht diese Anleitung zum Mocken einer 500 Internal Server Error Response tiefer ins Detail.

Nützliche nock-Funktionen

Einige Methoden tauchen ständig auf, sobald Sie über die Grundlagen hinausgehen.

• .persist() hält einen Interceptor über mehrere Aufrufe hinweg aktiv. Standardmäßig entfernt nock einen Interceptor, nachdem er einmal abgeglichen wurde, was hervorragend ist, um zu überprüfen, ob eine Anfrage genau einmal erfolgt ist. Verwenden Sie .persist(), wenn derselbe Endpunkt in einem Test wiederholt aufgerufen wird.
• .times(n) gleicht dieselbe Anfrage eine festgelegte Anzahl von Malen ab, bevor der Interceptor abläuft.
• .delay(ms) simuliert eine langsame Antwort, sodass Sie das Timeout-Handling testen können.
• RegExp-Matching ermöglicht es, dass der Host oder Pfad ein Muster anstelle einer festen Zeichenfolge ist, praktisch wenn IDs oder Abfrageparameter variieren.
• nock.cleanAll() löscht alle Interceptoren. Führen Sie es zwischen den Tests aus, damit die Mocks eines Tests nicht in den nächsten übergehen.

Eine Gewohnheit, die es sich lohnt, frühzeitig zu entwickeln: Vergewissern Sie sich, dass alle Ihre Mocks tatsächlich verwendet wurden. Rufen Sie scope.done() für einen Interceptor (oder nock.isDone()) auf, und der Test schlägt fehl, wenn eine erwartete Anfrage nie ausgelöst wurde. Das verwandelt einen stillen, verpassten Aufruf in ein lautes Scheitern.

Wo nock nicht mehr das richtige Werkzeug ist

nock ist für eine Aufgabe konzipiert und erledigt diese gut: HTTP innerhalb eines einzelnen Node-Prozesses während automatisierter Tests abfangen. Sobald Ihr Bedarf eine Prozessgrenze überschreitet, beginnt dieses Modell zu versagen.

Hier ist die Einschränkung. nock-Mocks leben in Ihrer Testdatei, in Ihrer Laufzeit, in Ihrer Sprache. Ein Frontend-Entwickler kann seinen Browser nicht auf Ihr nock-Setup richten. Ein Mobile-Entwickler kann es nicht von einem Simulator aus aufrufen. Ihr QA-Team kann keine manuellen Überprüfungen dagegen durchführen. Eine Postman-Sammlung kann es nicht erreichen. Der Mock existiert nur, solange Ihr Jest- oder Mocha-Prozess läuft, und nur für Code in demselben Prozess.

Das ist gut für Unittests und genau das, wofür nock entwickelt wurde. Aber viele reale Situationen erfordern einen Mock, der überall erreichbar ist:

• Das Frontend muss gegen einen Endpunkt entwickeln, bevor das Backend existiert.
• Drei Teams in verschiedenen Repos müssen sich auf dieselben gefälschten Antworten einigen.
• Sie möchten eine Integration ohne Live-Backend demonstrieren.
• Ein Tester möchte Grenzfälle manuell untersuchen, ohne Code zu benötigen.

Dafür benötigen Sie einen Mock-Server, etwas, das an einer echten URL lauscht und Antworten an jeden zurückgibt, der ihn aufruft. Wenn Sie die beiden Ideen abwägen, legen Mock-Server vs. echter Server und die umfassendere Erklärung zum API-Mocking die Kompromisse dar.

nock vs. ein gehosteter Mock-Server (Apidog)

Betrachten Sie es eher als zwei Schichten denn als einen Wettbewerb. nock übernimmt die In-Code-Interzeption für Unittests. Ein Tool wie Apidog bietet Ihnen einen gemeinsam genutzten, schema-gesteuerten Mock-Server für alles, was außerhalb eines einzelnen Testprozesses geschieht. Viele Teams verwenden beides.

Apidog generiert einen Mock-Server direkt aus Ihrem API-Design. Sie definieren einen Endpunkt und sein Schema, und Apidog liefert realistische Antworten unter einer Live-URL, mit intelligenten Mock-Regeln, die plausible Daten aus Feldnamen und -typen erzeugen. Keine Testumgebung, keine testspezifische Einrichtung, keine Sprachbindung. Jeder mit der URL erhält die gleichen Antworten.

Zur Verdeutlichung des Umfangs: Apidog ersetzt nock nicht in Ihren Jest- oder Mocha-Unittests. Wenn Sie einen fetch-Aufruf in einem einzelnen Test abfangen und das Ergebnis überprüfen müssen, ist nock immer noch das richtige Werkzeug. Apidog kommt ins Spiel, wenn der Mock eine Adresse benötigt, die andere Personen und andere Tools erreichen können. Für einen praktischen Einblick in die Serverseite, siehe den praktischen Leitfaden zum Mocken einer API für Tests. Sie können Apidog herunterladen und einen Mock aus einer bestehenden OpenAPI-Datei in wenigen Minuten erstellen.

Andere Alternativen zu nock

nock ist nicht die einzige Bibliothek in diesem Bereich, und die richtige Wahl hängt davon ab, wo Ihr Code ausgeführt wird.

• MSW (Mock Service Worker) fängt Anfragen auf Netzwerkebene ab, indem es einen Service Worker im Browser und einen Node-Interceptor auf dem Server verwendet. Dieselben Mock-Definitionen funktionieren in beiden Umgebungen, weshalb viele Teams dies heute standardmäßig für Full-Stack JavaScript verwenden. Die offizielle MSW-Dokumentation erklärt das Modell.
• Jest manual mocks ermöglichen es Ihnen, ein Modul wie axios durch einen Fake zu ersetzen. Dies ist für einen kleinen Fall einfacher als nock, bindet Sie aber an einen HTTP-Client. Das Jest Mocking Tutorial behandelt dieses Muster.
• Integrierte Test-Doubles im eigenen Test-Runner von Node oder Bibliotheken wie Sinon können die Funktion stubben, die den Aufruf tätigt, obwohl Sie dabei das HTTP-Level-Matching von nock verlieren.

Die entscheidende Frage ist immer dieselbe. Testen Sie Logik innerhalb eines Prozesses oder benötigen Sie eine Fake-API, die im Netzwerk existiert? nock und MSW beantworten die erste Frage. Ein gehosteter Mock-Server beantwortet die zweite.

Häufig gestellte Fragen

Ist nock kostenlos?

Ja. nock ist Open Source unter der MIT-Lizenz und kostenlos von npm zu installieren. Sie fügen es als Entwicklungsabhängigkeit hinzu und verwenden es kostenlos in Ihrer Testsuite.

Funktioniert nock mit fetch und axios?

Ja. Da nock auf der http-/https-Schicht von Node abfängt, funktioniert es mit jedem Client, der auf diesen Modulen aufbaut, einschließlich des nativen fetch, axios, got und node-fetch. Sie schreiben denselben Interceptor, unabhängig davon, welchen Ihr Code verwendet.

Kann ich nock im Browser verwenden?

Nein. nock ist nur für Node.js, da es die HTTP-Module von Node patcht, die im Browser nicht existieren. Für Browser-seitiges Mocking verwenden Sie MSW oder richten Ihr Frontend auf einen gehosteten Mock-Server aus. Dieser Überblick über Mock-APIs in JavaScript erläutert die Browser-Optionen.

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

nock fängt Anfragen innerhalb Ihres Testprozesses ab und öffnet niemals einen echten Port. Ein Mock-Server lauscht an einer echten URL, die jeder Client aufrufen kann. Verwenden Sie nock für Unittests; verwenden Sie einen Mock-Server, wenn das Frontend, die Qualitätssicherung oder andere Teams dieselben gefälschten Antworten erreichen müssen.

Zusammenfassung

nock ist die zuverlässige Wahl für HTTP-Mocking in Node.js-Unittests. Es fängt ausgehende Anfragen im Prozess ab, gibt die von Ihnen definierten Antworten zurück und macht Ihre Testsuite schnell und deterministisch, einschließlich der Fehlerpfade, die Sie nicht gegen eine Live-API auslösen können. Verwenden Sie es weiterhin dafür.

Wenn der Mock Ihre Testdatei verlassen muss, wenn das Frontend, die Qualitätssicherung oder ein anderes Team denselben Endpunkt treffen muss, greifen Sie stattdessen zu einem gemeinsam genutzten Mock-Server. Apidog generiert einen aus Ihrem API-Schema und liefert realistische Daten unter einer Live-URL, sodass jeder vor der Fertigstellung des Backends auf der Grundlage desselben Vertrags entwickeln kann. Laden Sie Apidog herunter und verwandeln Sie Ihre OpenAPI-Spezifikation in wenigen Minuten in einen funktionierenden Mock.