Eine Mock-API ist eine gefälschte API, die sich wie eine echte verhält. Sie akzeptiert dieselben Anfragen, liefert Antworten in derselben Form und befindet sich unter einer URL, die Sie aufrufen können, aber hinter dieser URL gibt es keine echte Datenbank, keine Geschäftslogik und keinen echten Dienst. Die Antwort ist etwas, das Sie im Voraus definiert haben.
Das klingt trivial, und die Idee ist es auch. Der Wert ergibt sich aus dem, was es Ihnen ermöglicht: das Entwickeln und Testen anhand einer Schnittstelle, bevor das eigentliche Element dahinter existiert oder während das reale Element zu langsam, zu kostspielig oder zu unzuverlässig ist, um aufgerufen zu werden. Dieser Erklärtext definiert den Begriff präzise, trennt einen Mock von den Dingen, mit denen er verwechselt wird, und erläutert die Unterscheidung zwischen statisch und dynamisch, die das Verhalten eines Mock bestimmt.
Was eine Mock-API tatsächlich ist
Im Grunde ist eine Mock-API eine Anfrage-Antwort-Zuordnung. Eine Anfrage kommt herein. Der Mock gleicht sie mit von Ihnen festgelegten Regeln ab, wählt eine Antwort aus und sendet sie zurück. Dazwischen findet keine Berechnung statt, es sei denn, Sie fordern diese an.
Ein Mock besteht aus drei Teilen. Es gibt die Schnittstelle: die Routen, Methoden und Parameter, die sie akzeptiert und die genau der echten API entsprechen sollten. Es gibt die Antwortdefinition: die Bodies, Statuscodes und Header, die sie zurückgibt. Und es gibt die Abgleichlogik: wie der Mock entscheidet, welche Antwort eine gegebene Anfrage erhält, von einem einfachen Pfadabgleich bis hin zu Regeln, die sich nach Abfrageparametern oder Headern verzweigen.
Da die Schnittstelle der echten API entspricht, weiß der Code, der den Mock aufruft, nicht, dass er gefälscht ist. Tauschen Sie die Basis-URL aus, und derselbe Client kommuniziert mit dem echten Dienst. Diese Austauschbarkeit ist der entscheidende Punkt. Eine praktische Anleitung zum Erstellen eines solchen finden Sie in diesem Leitfaden zum Mocken einer API zum Testen.
Es ist hilfreich, genau zu definieren, was eine Mock-API nicht ist. Es ist kein Cache, denn ein Cache speichert echte Antworten und ein Mock erfindet sie. Es ist keine Sandbox, denn eine Vendor-Sandbox führt echte, vereinfachte Logik aus, während ein Mock überhaupt keine Logik ausführt. Und es ist keine Staging-Umgebung, denn Staging ist eine vollständige Bereitstellung des realen Systems. Ein Mock ist leichter als alle drei: Es ist lediglich die Eingangstür einer API mit vordefinierten Antworten dahinter, und sonst nichts.
Mock versus Stub
Die Begriffe „Mock“ und „Stub“ werden austauschbar verwendet, bedeuten aber im Testen unterschiedliche Dinge.
Ein Stub ist die einfachere Idee. Er gibt eine fest vorgegebene Antwort auf einen Aufruf zurück und nichts weiter. Fragen Sie ihn nach einem Benutzer, gibt er einen festen Benutzer zurück. Ein Stub hat keine Meinung darüber, wie er aufgerufen wurde.
Ein Mock, im strengen Testsinn, verifiziert auch die Interaktion. Er kann bestätigen, dass er aufgerufen wurde, wie oft und mit welchen Argumenten. Ein Mock kann Ihren Test fehlschlagen lassen, weil der Aufruf falsch war, nicht nur einen Wert liefern.
Im täglichen API-Arbeit ist die Grenze verschwommen, und „Mock-API“ umfasst gewöhnlich beides. Die nützliche Erkenntnis: Ein Stub antwortet, ein Mock antwortet und überwacht. Wenn Ihr Test nur die Daten betrifft, die Ihr Code empfängt, ist eine Stub-ähnliche Antwort ausreichend. Wenn es darum geht, ob Ihr Code den richtigen Aufruf auf die richtige Weise gemacht hat, wünschen Sie die Verifizierung, die ein echter Mock hinzufügt. Für ein breiteres Vokabular siehe den Unterschied zwischen Validierung und Verifizierung.
Zwei weitere Begriffe liegen nahe. Ein Fake ist eine funktionierende, aber vereinfachte Implementierung, wie eine In-Memory-Datenbank, die anstelle einer echten verwendet wird; sie hat Logik, nur weniger davon. Ein Spy umschließt ein reales Objekt und zeichnet auf, wie es aufgerufen wurde, ohne sein Verhalten zu ändern. Eine Mock-API, wie der Begriff in der API-Entwicklung verwendet wird, ist einem Stub mit optionaler Verifizierung am ähnlichsten, der über HTTP unter einer echten URL bereitgestellt wird. Sie müssen das Vokabular nicht überwachen, aber das Wissen um das Spektrum hilft Ihnen, Testdokumentationen zu lesen, ohne sich zu verirren.
Mock-API versus realer Server
Ein echter Server und ein Mock-Server können unter derselben URL liegen und denselben JSON-Code zurückgeben, der Unterschied liegt also darin, was hinter dem Endpunkt geschieht.
| Mock-API | Echter Server | |
|---|---|---|
| Hinter dem Endpunkt | Vordefinierte Antworten | Live-Logik und eine Datenbank |
| Antwortquelle | Regeln, die Sie geschrieben haben | Pro Anfrage berechnet |
| Daten | Fest oder generiert | Real, persistent |
| Nebenwirkungen | Keine | Schreiben, Belastungen, E-Mails |
| Geschwindigkeit | Schnell und konstant | Variiert mit der Last |
| Korrektheit | Entspricht dem, was Sie definiert haben | Entspricht dem tatsächlichen Verhalten |
Ein echter Server sagt Ihnen die Wahrheit: Er führt den tatsächlichen Code aus und beweist, dass das System funktioniert. Er ist auch langsam, zustandsbehaftet und kann echte Nebenwirkungen haben, sodass ein Test dagegen eine Karte belasten oder eine E-Mail senden kann.
Ein Mock-Server sagt Ihnen nur, was Sie ihm mitgeteilt haben. Er ist schnell, frei von Nebenwirkungen und perfekt vorhersehbar, was ihn ideal für die Entwicklung und die meisten Tests macht. Aber ein Mock kann falsch sein und es nie wissen, weil er die echte Logik nicht ausführt. Deshalb behalten Sie einige Tests auf dem echten Server. Der Kompromiss wird ausführlich in Mock-Server versus realem Server behandelt.
Statische und dynamische Mocks
Ein Mock gibt seine Antwort auf eine von zwei Arten zurück, und die Wahl bestimmt, wie sich der Mock bei der Verwendung anfühlt.
Ein statischer Mock gibt eine feste Nutzlast zurück. Sie schreiben den genauen JSON-Code einmal, und jede passende Anfrage erhält denselben identischen Body zurück. Statische Mocks sind vorhersehbar, was sie leicht überprüfbar macht. Ihre Schwäche ist der Realismus: Eine einzige fest codierte Nutzlast wird einen Fehler im Code, der bei langen Zeichenketten, leeren Arrays oder unerwarteten Nullwerten auftritt, nicht aufdecken.
Ein dynamischer Mock generiert die Antwort pro Anfrage. Anstelle eines festen "id": "user_1001" erzeugt er bei jedem Aufruf eine neue UUID. Statt eines Namens gibt er jedes Mal einen anderen realistischen Namen zurück. Dynamische Mocks steuern dies normalerweise mit einer Datengenerierungsgrammatik wie Faker.js, sodass ein Feld namens email eine E-Mail und created_at ein Datum liefert. Sie sind realistischer und besser darin, Grenzfälle aufzudecken, auf Kosten dessen, dass sie schwieriger exakt zu überprüfen sind.
Die meisten Teams verwenden beides. Statische Mocks für assertionslastige Unit-Tests, bei denen Sie einen bekannten Wert benötigen. Dynamische Mocks für die Entwicklung, Demos und Fuzz-ähnliche Abdeckung, wo Vielfalt wichtiger ist als eine feste Antwort.
Ein dynamischer Mock kann auch bedingt sein, was über die einfache Generierung hinausgeht. Ein bedingter Mock verzweigt sich je nach Anfrage: Eine Anfrage für /orders/404 gibt einen 404 zurück, eine Anfrage mit einem ungültigen Token gibt einen 401 zurück, und alles andere gibt einen normalen 200 zurück. Ein Mock-Endpunkt deckt dann den „Happy Path“ und mehrere Fehlerpfade gleichzeitig ab. Dies macht einen Mock für Tests wirklich nützlich, da er Fehlerantworten reproduzieren kann, die ein gesunder echter Server nicht auf Anforderung produzieren würde.
Wo eine Mock-API in der Entwicklung passt
Eine Mock-API ist an drei Stellen nützlich. Frühzeitig ermöglicht sie es Frontend- und Backend-Teams, sich auf einen Vertrag zu einigen und parallel zu entwickeln, sodass keiner auf den anderen warten muss. Während des Testens isoliert sie Ihren Code von Netzwerkschwankungen und ermöglicht es Ihnen, Fehlerantworten auszulösen, die ein echter Server nicht auf Anforderung produzieren würde. Und für Demos und Prototypen liefert sie kontrollierte, vorhersehbare Daten ohne eine Live-Abhängigkeit, die mitten in der Präsentation versagen könnte. Diese Szenarien werden in diesem Leitfaden zu Anwendungsfällen für API-Mocking genauer untersucht.
Das wiederkehrende Risiko ist die Drift. Ein Mock ist eine Momentaufnahme einer Schnittstelle, und Schnittstellen ändern sich. Wenn die echte API ein Feld hinzufügt oder umbenennt, liefert ein nicht verbundener Mock weiterhin die alte Form, und Ihre Tests bestehen gegen einen Vertrag, der nicht mehr existiert.
Die Lösung besteht darin, den Mock als abgeleitet und nicht als manuell erstellt zu behandeln. Generieren Sie ihn aus demselben Schema, das die echte API veröffentlicht, sodass eine Vertragsänderung den Mock neu generiert. Ein Mock, den Sie von Hand eingegeben haben, ist eine Kopie, die sofort veraltet; ein aus der Spezifikation generierter Mock ist immer eine aktuelle Momentaufnahme. Der Unterschied zeigt sich nicht am ersten Tag, aber er entscheidet, ob der Mock nach sechs Monaten noch vertrauenswürdig ist. Apidog funktioniert so: Sie entwerfen die API einmal, und der Mock-Endpunkt wird aus diesem Design mit realistischen Daten generiert, die aus Feldnamen abgeleitet werden. Der Mock, die Dokumentation und das API-Vertragstesting lesen alle aus einer einzigen Quelle, sodass sie synchron bleiben. Um den Design-zu-Mock-Workflow von Anfang bis Ende zu sehen, laden Sie Apidog herunter.
Häufig gestellte Fragen
Was ist eine Mock-API einfach ausgedrückt?
Eine Mock-API ist eine gefälschte API, die eine echte imitiert. Sie stellt dieselben Routen bereit und gibt Antworten in derselben Form zurück, aber dahinter steckt keine echte Logik oder Datenbank. Die Antworten sind vordefiniert, was Ihnen ermöglicht, anhand der Schnittstelle zu entwickeln und zu testen, bevor der echte Dienst existiert.
Was ist der Unterschied zwischen einem Mock und einem Stub?
Ein Stub gibt eine fest vorgegebene Antwort zurück und nichts weiter. Ein Mock, im strengen Testsinn, verifiziert auch die Interaktion, sodass er überprüfen kann, ob er die richtige Anzahl von Malen mit den richtigen Argumenten aufgerufen wurde. Ein Stub antwortet; ein Mock antwortet und überwacht.
Wie unterscheidet sich eine Mock-API von einem realen Server?
Ein Mock gibt vordefinierte Antworten ohne echte Berechnung zurück, daher ist er schnell, vorhersehbar und hat keine Nebenwirkungen. Ein realer Server führt die tatsächliche Logik gegen eine echte Datenbank aus, daher ist er langsamer und zustandsbehaftet, beweist aber, dass das System wirklich funktioniert. Verwenden Sie einen Mock für die Entwicklung und den realen Server für Vertrags- und End-to-End-Tests.
Sollte ich einen statischen oder einen dynamischen Mock verwenden?
Verwenden Sie einen statischen Mock, wenn Sie einen vorhersehbaren Wert benötigen, um ihn zu überprüfen, was für Unit-Tests geeignet ist. Verwenden Sie einen dynamischen Mock, wenn Sie realistische, vielfältige Daten wünschen, die Grenzfälle abfangen, was für die Entwicklung und Demos geeignet ist. Viele Teams verwenden beides.
Wie verhindere ich, dass eine Mock-API ungenau wird?
Generieren Sie den Mock aus demselben Schema, das die reale API veröffentlicht, anstatt ihn von Hand zu schreiben. Wenn sich der Vertrag ändert, wird der Mock neu generiert. Die Absicherung mit geplanten Vertragstests gegen die reale API fängt jede verbleibende Drift frühzeitig ab.