Wenn Ihr Team mit Keploy begonnen hat, lieben Sie wahrscheinlich eine Sache daran: Sie haben Ihre App ausgeführt, ein paar Endpunkte aufgerufen, und Tests sind erschienen. Kein Schreiben von Assertions, kein manuelles Stubben von Abhängigkeiten. Keploy erfasst echten Datenverkehr auf der Netzwerkschicht und spielt ihn für Sie wieder ab.
Warum sollte also jemand von Keploy wegwechseln wollen? Normalerweise liegt es an einem anderen Bedürfnis. Erfasste Tests sind großartig, um Regressionen in bereits Geschehenem zu erkennen, aber sie sind schwieriger zu lesen, zu überprüfen und teamübergreifend zu pflegen. Irgendwann möchte man Tests haben, die ein neuer Ingenieur in einem Pull Request öffnen, auf einen Blick verstehen und absichtlich ändern kann. Sie möchten Testdaten, die Sie kontrollieren, Umgebungen, die Sie mit einem Flag umschalten können, und Mock-Server, die Sie entwerfen, anstatt solche, die aus einer Aufzeichnung abgeleitet wurden.
Zwei verschiedene Paradigmen, ehrlich verglichen
Keploy und Apidog überschneiden sich bei den Worten „API-Tests“, aber sie gehören zu verschiedenen Werkzeugkategorien. So zu tun, als wäre es anders, würde Ihnen einen Bärendienst erweisen.
Keploy ist eine Open-Source-Plattform zum Erstellen isolierter Test-Sandboxes. Ihre Spezialität ist das Aufzeichnen und Wiederabspielen: Mit eBPF auf der Netzwerkschicht erfasst es echte API-Aufrufe und deren Abhängigkeiten (Datenbankabfragen, nachgeschaltete Dienste, Streaming-Ereignisse) ohne SDK und ohne Codeänderungen. Aus diesem erfassten Datenverkehr generiert es automatisch Testfälle und Mocks für diese Abhängigkeiten. Es verfügt auch über einen KI-Testgenerierungspfad, der Suiten aus einer OpenAPI-Spezifikation, einer Postman-Sammlung, einem cURL-Befehl oder einem Live-Endpunkt erstellt. Da die Erfassung auf der eBPF-Schicht erfolgt, ist sie sprachunabhängig und basiert auf Linux und erhöhten Berechtigungen. Den Quellcode können Sie auf GitHub lesen.
Apidog ist eine All-in-One-API-Plattform: Design, Debugging, Mocking, Dokumentation und Tests an einem Ort. Die Apidog CLI (apidog run) führt von Ihnen erstellte Testszenarien und Sammlungen aus, von Ihrem Terminal und in CI/CD. Es unterstützt datengesteuertes Testen, Umgebungswechsel, mehrere Berichtsformate und Cloud-Berichte. Apidog verfügt auch über eine KI-gestützte Testfallgenerierung, die jedoch auf Ihrem API-Schema und den Endpunkten innerhalb der App basiert und nicht durch die Aufzeichnung von Produktionsdatenverkehr.
Hier ist die ehrliche Einschätzung, die Sie benötigen, bevor Sie etwas planen: Apidog erfasst keinen Live-Datenverkehr über eBPF und generiert keine Tests automatisch durch Aufzeichnung von Produktionsaufrufen plus Abhängigkeits-Mocks. Das ist die besondere Stärke von Keploy. Wenn die Laufzeiterfassung der Kern Ihres Workflows ist, behalten Sie Keploy für diese Aufgabe. Was Sie durch den Wechsel zu Apidog gewinnen, sind entworfene, überprüfbare, teamübergreifende Tests und eine Plattform, die den gesamten API-Lebenszyklus abdeckt.
| Keploy-Ansatz | Apidog-Ansatz |
|---|---|
keploy record erfasst echten Datenverkehr über eBPF |
Importieren Sie Ihre API-Oberfläche als OpenAPI, Postman oder cURL |
| Tests werden automatisch aus erfassten Aufrufen generiert | KI-Testfallgenerierung aus der Spezifikation, plus von Ihnen erstellte Szenarien |
keploy test --delay 10 spielt Aufzeichnungen wieder ab |
apidog run führt erstellte Szenarien in CI aus |
| Abhängigkeits-Mocks, die aus echtem DB-/Netzwerkverkehr erfasst wurden | Von Ihnen entworfene und kontrollierte Mock-Server |
| Testdaten, die in die Aufzeichnung integriert sind | Datengesteuertes Testen über -d (CSV/JSON), das Sie pflegen |
| Implizite Umgebung aus dem aufgezeichneten Durchlauf | Explizite Umgebungen, die mit -e umgeschaltet werden |
| Linux/eBPF, erhöhte Berechtigungen | Läuft überall dort, wo die CLI läuft, einschließlich Standard-CI-Runnern |
Lesen Sie diese Tabelle als Übersetzungsanleitung, nicht als Feature-Scorecard. Jede Keploy-Funktion entspricht einem bewussten Erstellungsschritt in Apidog. Sie tauschen „das Tool hat es aus dem Datenverkehr herausgefunden“ gegen „Sie haben beschrieben, wie korrekt aussieht“.
Schritt 1: Erfassen Sie Ihre API-Oberfläche als Spezifikation
Keploy beginnt mit einer laufenden App. Apidog beginnt mit einer Beschreibung Ihrer API. Die erste Aufgabe besteht also darin, diese Beschreibung zu erhalten.
Wenn Sie bereits ein OpenAPI-Dokument veröffentlichen, sind Sie fertig. Zeigen Sie darauf und fahren Sie fort. Wenn nicht, haben Sie ein paar Optionen, die alle etwas Importierbares erzeugen:
- Generieren Sie OpenAPI aus Ihrem Framework (die meisten modernen Frameworks verfügen über einen Exporter oder eine Bibliothek, die es ausgibt).
- Exportieren Sie eine Postman-Sammlung, wenn Ihr Team bereits eine pflegt.
- Sammeln Sie die cURL-Befehle, die Sie verwenden, um jeden Endpunkt aufzurufen.
Ein netter Nebeneffekt: Wenn Sie Keploy-Aufzeichnungen haben, sind die erfassten Anfragen ein echtes Inventar, welche Endpunkte tatsächlich aufgerufen werden und mit welchen Payloads. Verwenden Sie sie als Checkliste, damit Ihre Spezifikation dieselbe Oberfläche abdeckt, auch wenn Sie die Aufzeichnungen selbst nicht importieren werden.
Schritt 2: Importieren in Apidog
Laden Sie Apidog herunter, erstellen Sie ein Projekt und importieren Sie Ihre OpenAPI-Datei, Postman-Sammlung oder cURL-Befehle. Apidog liest die Spezifikation und füllt Endpunkte, Anfrage-Schemata, Parameter und Antwortmodelle aus. Sie haben nun eine strukturierte Definition jedes Endpunkts, dieselbe Oberfläche, die Keploy getroffen hat, aber in einer Form, die Sie bearbeiten, versionieren und teilen können.
Dies ist auch der Moment, in dem der Plattformunterschied sichtbar wird. Diese importierten Endpunkte sind nicht nur Test-Fixtures. Sie sind Live-Dokumentation, debuggbare Anfragen und die Basis für Mock-Server, alles aus einem einzigen Import. Für eine Schritt-für-Schritt-Anleitung zur Toolchain deckt der Apidog CLI Complete Guide die vollständige Einrichtung ab.
Schritt 3: Eine Start-Testsuite generieren und dann die realen Szenarien erstellen
Hier gewinnen Sie einen Teil der Geschwindigkeit zurück, die Sie an Keploy mochten. Die KI-Testfallgenerierung von Apidog liest Ihr importiertes Schema und die Endpunkte und entwirft Testfälle für Sie: gültige Anfragen, Grenzwerte und häufige Fehlerantworten basierend auf der Spezifikation. Es ist ein starker Ausgangspunkt und bringt Sie schnell von einem leeren Blatt weg. Wenn Sie sehen möchten, wie sich dies über verschiedene Tools verhält, stellt die Übersicht über die besten KI-Testfallgeneratoren dies in den Kontext.
Zwei ehrliche Anmerkungen. Erstens benötigen KI-generierte Fälle (in Apidog oder Keploy) einen menschlichen Überprüfungsschritt. Betrachten Sie das Ergebnis als Entwurf, entfernen Sie, was nicht zutrifft, und verschärfen Sie die Assertions. Zweitens ist dies eine Generierung aus einer Spezifikation, nicht aus Laufzeitverhalten, sodass es keine Besonderheit erkennen wird, die nur unter realen Produktionsdaten auftritt. Genau diese Lücke hat Keploys Erfassung geschlossen, und es ist die Lücke, die Sie akzeptieren, wenn Sie zu entworfenen Tests übergehen.
Dann erstellen Sie die Szenarien, die wichtig sind. Ein Szenario verkettet Anfragen zu einem echten Ablauf: Benutzer erstellen, mit dem zurückgegebenen Token anmelden, Profil abrufen, aktualisieren, löschen. Sie prüfen Statuscodes, Antwortfelder und wie Daten von einem Schritt zum nächsten übertragen werden. Dies ist die Arbeit, die Keploy implizit in einer Aufzeichnung erledigt hat. Es explizit zu tun, ist anfangs mehr Aufwand, und es zahlt sich jedes Mal aus, wenn jemand den Test später liest, überprüft oder ändert. Der Leitfaden zum Schreiben von Testfällen mit KI-Unterstützung hilft Ihnen, Generierung und manuelle Erstellung in Einklang zu bringen.
Schritt 4: Umgebungen und datengesteuerte Eingaben festlegen
Eine Aufzeichnung enthält einen Satz von Werten aus einem Durchlauf. Erstellte Tests sollten gegen jede Umgebung mit jedem Datensatz laufen.
Definieren Sie Umgebungen in Apidog (lokal, Staging, Produktion) mit eigenen Basis-URLs, Tokens und Variablen. Zur Laufzeit wählen Sie eine mit -e aus. Für Testdaten hängen Sie eine CSV- oder JSON-Datei an, und Apidog führt jedes Szenario einmal pro Zeile aus, sodass ein Anmeldeszenario ein Dutzend Anmeldeinformationskombinationen abdeckt. Sie verweisen mit -d auf die Datei. Der Leitfaden für datengesteuertes Testen zeigt die Dateiformate und Variablenbindung im Detail.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-d ./test-data/login-cases.csv
Dies ist eine konkrete Verbesserung gegenüber einer festen Aufzeichnung. Ihre Testdaten sind eine Datei, die Sie besitzen, in Pull Requests überprüfen und erweitern können, wenn neue Edge Cases auftreten.
Schritt 5: Ausführen in CI mit apidog run
Der Befehl, der keploy test in Ihrer Pipeline ersetzt, ist apidog run. Er führt Ihre erstellten Szenarien aus, wendet die ausgewählte Umgebung und Datendatei an und erstellt Berichte. Sie können CLI-, HTML- und JSON-Ausgaben erzeugen und Ergebnisse mit --upload-report in die Cloud hochladen, um einen teilbaren Link zu erhalten.
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-i 123456 \
-e "staging" \
-r html,cli \
--upload-report
Die Integration in Ihre Pipeline hat die gleiche Form wie jeder CI-Testschritt: Installieren Sie die CLI, übergeben Sie Ihr Token und Ihre Szenario-ID, lassen Sie den Build bei einem Nicht-Null-Exit fehlschlagen. Der CI/CD-Pipeline-Leitfaden und die GitHub Actions-Anleitung behandeln das genaue YAML, und der Testberichte-Leitfaden erklärt, wie Sie die Ausgabe lesen, die Ihr Team tatsächlich betrachten wird.
Schritt 6: Mock-Server erstellen, die Sie kontrollieren
Keploy bietet Ihnen Mocks kostenlos, indem es den Abhängigkeitsverkehr während der Aufzeichnung erfasst. Apidog geht den anderen Weg: Sie entwerfen den Mock. Da Sie Ihr Schema bereits importiert haben, kann Apidog daraus einen Mock-Server generieren, der realistische Beispielantworten basierend auf Feldtypen und von Ihnen festgelegten Regeln zurückgibt. Sie entscheiden über Latenz, Fehlerfälle und die genauen Payloads.
Der Kompromiss ist derselbe wie überall sonst in diesem Leitfaden. Erfasste Mocks spiegeln wider, was Ihre Abhängigkeiten tatsächlich getan haben; entworfene Mocks spiegeln wider, was Sie entschieden haben, dass sie tun sollten. Für Vertragsprüfungen und stabile CI tendieren entworfene Mocks zum Erfolg, weil sie nicht mit der Produktion abweichen. Wenn Sie die tieferen Hintergründe erfahren möchten, siehe Vertragsprüfung und Mocking-Tools und Generierung von Mock-Daten aus OpenAPI-Schemas.
Was Sie behalten und was Sie aufgeben
Seien Sie Ihrem Team gegenüber ehrlich über beide Seiten dieses Wechsels.
Sie geben die automatische Erfassung auf. Kein keploy record, das den echten Datenverkehr überwacht, keine aus Produktionsläufen abgeleiteten Abhängigkeits-Mocks, keine eBPF-Magie, die null Code erfordert. Wenn diese Fähigkeit für Sie tragend ist, behalten Sie Keploy dafür im Werkzeugkasten. Die beiden Tools können koexistieren.
Sie gewinnen Tests, die wie Dokumentation lesbar sind, Umgebungen, die Sie mit einem Flag umschalten können, Testdaten, die Sie besitzen und überprüfen, Mock-Server, die Sie entwerfen, und eine einzige Plattform für Design, Debugging, Dokumentation und Tests. Die Kosten sind real (das Erstellen erfordert mehr Aufwand als das Aufzeichnen), und der Gewinn ist eine Wartbarkeit, die Ihr gesamtes Team nutzen kann. Die breitere Übersicht der API-Testautomatisierungstools ordnet diese Kompromisse ein, und wie man eine API mit Apidog testet ist eine gute nächste praktische Lektüre.
Wenn Sie die beiden Tools nebeneinander abwägen, zerlegt der Vergleich von Apidog und Keploy die Funktionen im Detail, und wenn Keploy für Ihr Team nicht passt, lohnt sich ein Blick auf die Liste der besten Keploy-Alternativen.
FAQ
Kann Apidog meine bestehenden Keploy-Aufzeichnungen importieren? Nicht direkt. Keploy-Aufzeichnungen sind Laufzeit-Erfassungen, und Apidog arbeitet mit API-Spezifikationen. Der praktische Weg ist, Ihre API-Oberfläche als OpenAPI (oder Postman/cURL) zu erfassen und diese zu importieren. Verwenden Sie Ihre Keploy-Aufzeichnungen als Checkliste, welche Endpunkte abgedeckt werden sollen.
Zeichnet Apidog Live-Traffic auf und mockt meine Datenbank automatisch wie Keploy? Nein. Apidog erfasst keinen Traffic über eBPF und generiert keine Abhängigkeits-Mocks automatisch aus echten Läufen. Das ist Keploys besondere Stärke. Apidog generiert Tests und Mocks aus Ihrem Schema, und Sie erstellen darauf aufbauend Szenarien.
Was ersetzt keploy record und keploy test? Es gibt kein Äquivalent zu record. Stattdessen importieren Sie eine Spezifikation, generieren eine Startsuite mit KI, erstellen Szenarien und führen diese mit apidog run anstelle von keploy test aus.
Lohnt sich der zusätzliche Erstellungsaufwand, um von Keploy zu migrieren? Wenn Sie Tests wünschen, die lesbar, in Pull Requests überprüfbar und teamübergreifend gepflegt sind, ja. Wenn Ihr Hauptbedürfnis die mühelose Erfassung echten Laufzeitverhaltens einschließlich Abhängigkeits-Mocks ist, leistet Keploy das immer noch besser, also behalten Sie es für diese Aufgabe.
Kann ich beide Tools gleichzeitig ausführen? Ja. Viele Teams verwenden Keploy für auf Erfassung basierende Regressionstests und Apidog für entworfene End-to-End-Suiten, Dokumentation und Mocks. Sie lösen unterschiedliche Probleme.
Wo anfangen
Wählen Sie einen Dienst. Exportieren Sie seine OpenAPI-Spezifikation, importieren Sie sie in Apidog, lassen Sie die KI einige Testfälle entwerfen und erstellen Sie dann ein echtes Szenario mit einer Umgebung und einer kleinen Datendatei. Führen Sie es mit apidog run aus und integrieren Sie es in CI. Sobald dieser Ablauf gut funktioniert, erweitern Sie ihn. Sie tauschen den Komfort der Aufzeichnung gegen Tests, die Ihr gesamtes Team lesen, ändern und vertrauen kann. Um tiefer in die CLI selbst einzusteigen, beginnen Sie mit der Installationsanleitung und der Befehlszeilen-REST-API-Testanleitung.