Projektbeschreibung
ÜbersetztWir bauen ein neues Webprodukt und das Frontend-Team ist untätig, während es auf ein Backend wartet, das noch mehrere Wochen nicht bereit sein wird. Wir benötigen einen dedizierten Mock-Server, der unsere OpenAPI-Spezifikation liest und an die Stelle des echten Dienstes tritt, indem er vorhersehbare vorgefertigte Antworten für jeden beschriebenen Endpunkt bereitstellt. Das Ziel ist es, einen stabilen Vertrag zu erhalten, gegen den Client-Anwendungen jetzt entwickelt und demonstriert werden können, sodass beim Eintreffen des echten Backends der Wechsel nur eine Frage der Änderung der Basis-URL ist. Dies ist speziell ein Mocking- und Stub-Tool, kein API-Gateway oder Test-Framework: Routing, Autorisierungs-Proxy und Assertionsbibliotheken werden nicht benötigt, nur authentische gefälschte Antworten.
Der Mock sollte die Spezifikation parsen und automatisch Payload-Beispiele aus deklarierten Schemata generieren, aber auch manuelles Überschreiben jeder Route mit einem benutzerdefinierten Antwortkörper, der an Pfad, Methode und Statuscode gebunden ist, ermöglichen. Ich möchte auf Abruf reale Bedingungen simulieren: konfigurierbare Verzögerung für jeden Endpunkt, erzwungene Fehlercodes wie 400, 401, 404, 429 und 500 sowie die Möglichkeit, unterschiedliche Antworten basierend auf einem Anfrage-Header oder Flag zurückzugeben, damit das Team sowohl glückliche Pfade als auch Fehlerbehandlung testen kann. Antwort-Fixierungen sollten in einfachen Dateien leben, die wir in Git speichern, und das Neuladen sollte keinen Neustart erfordern. Eine kleine Konfiguration kann globale Standardwerte für Verzögerung und Fehlerquoten festlegen.
Ich erwarte als Ausgabe einen einzigen Dienst, der lokal mit einem Befehl startet und sich auf die gleiche Weise in einem Container für eine gemeinsame Umgebung einfügt. Fügen Sie klare Anweisungen und ein paar fertige Szenarien hinzu.
— OpenAPI-Spezifikation parsen und Antwortbeispiele für jeden Endpunkt generieren
— Antworten nach Pfad, Methode und Status über bearbeitbare Fixture-Dateien überschreiben
— Verzögerungen, Zeitüberschreitungen und erzwungene Fehlercodes auf Abruf simulieren
— Hot Reload von Fixtures ohne Neustart des Servers
— Lokal mit einem Befehl plus Container-Image für Staging ausführen
Der Mock sollte die Spezifikation parsen und automatisch Payload-Beispiele aus deklarierten Schemata generieren, aber auch manuelles Überschreiben jeder Route mit einem benutzerdefinierten Antwortkörper, der an Pfad, Methode und Statuscode gebunden ist, ermöglichen. Ich möchte auf Abruf reale Bedingungen simulieren: konfigurierbare Verzögerung für jeden Endpunkt, erzwungene Fehlercodes wie 400, 401, 404, 429 und 500 sowie die Möglichkeit, unterschiedliche Antworten basierend auf einem Anfrage-Header oder Flag zurückzugeben, damit das Team sowohl glückliche Pfade als auch Fehlerbehandlung testen kann. Antwort-Fixierungen sollten in einfachen Dateien leben, die wir in Git speichern, und das Neuladen sollte keinen Neustart erfordern. Eine kleine Konfiguration kann globale Standardwerte für Verzögerung und Fehlerquoten festlegen.
Ich erwarte als Ausgabe einen einzigen Dienst, der lokal mit einem Befehl startet und sich auf die gleiche Weise in einem Container für eine gemeinsame Umgebung einfügt. Fügen Sie klare Anweisungen und ein paar fertige Szenarien hinzu.
— OpenAPI-Spezifikation parsen und Antwortbeispiele für jeden Endpunkt generieren
— Antworten nach Pfad, Methode und Status über bearbeitbare Fixture-Dateien überschreiben
— Verzögerungen, Zeitüberschreitungen und erzwungene Fehlercodes auf Abruf simulieren
— Hot Reload von Fixtures ohne Neustart des Servers
— Lokal mit einem Befehl plus Container-Image für Staging ausführen
Texte und Übersetzung Bargeld, Banküberweisung
