DEV Community

Cover image for ReadyAPI zu Apidog migrieren
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

ReadyAPI zu Apidog migrieren

TL;DR

Die Migration von ReadyAPI zu Apidog ist für REST-lastige Test-Suites unkompliziert. Exportieren Sie Ihr ReadyAPI-Projekt, konvertieren Sie, was Sie können, über den OpenAPI-Import und erstellen Sie Groovy-Skripte manuell in JavaScript neu. SOAP-Testfälle erfordern die meiste manuelle Arbeit. Planen Sie eine phasenweise Migration, um eine durchgehende Testabdeckung zu gewährleisten.

Testen Sie Apidog noch heute

💡Apidog ist eine kostenlose All-in-One-Plattform für die API-Entwicklung, die OpenAPI-Spezifikationen und Postman-Sammlungen importiert und Test-Pipelines mit JavaScript-Skripten ausführt. Testen Sie Apidog kostenlos, keine Kreditkarte erforderlich.

Einleitung

Die Migration von API-Testinfrastrukturen ist eine jener Aufgaben, die zunächst einfach klingen, bis man damit beginnt. ReadyAPI-Projekte können jahrelang angesammelte Testfälle, benutzerdefinierte Groovy-Skripte, Datendateien, Umgebungen und komplexe Test-Suite-Strukturen enthalten. All dies in Apidog zu integrieren, erfordert ein Verständnis dafür, was automatisch übertragen wird, was manuell konvertiert werden muss und was Sie möglicherweise zurücklassen möchten.

Dieser Leitfaden zeigt Ihnen Schritt für Schritt, wie Sie Ihr ReadyAPI-Projekt exportieren, die Elemente analysieren, die Migration per OpenAPI-Import durchführen, Groovy-Skripte nach JavaScript umschreiben, CI/CD aufsetzen und beide Tools während der Umstellung parallel betreiben.

Schritt 1: ReadyAPI-Projekt prüfen

Starten Sie mit einem strukturierten Audit:

  1. Öffnen Sie Ihr ReadyAPI-Projekt.
  2. Prüfen Sie:
    • Anzahl der Test-Suites, Testfälle, Testschritte: Im Navigator-Panel zählen.
    • REST vs. SOAP-Anteil: REST ist einfacher zu migrieren.
    • Groovy-Skripting: Wie viele Testfälle nutzen eigene Groovy-Skripte? Jeder Groovy-Schritt muss manuell nach JavaScript konvertiert werden.
    • Datengesteuerte Tests: Werden DataSource/DataSink-Schritte genutzt? Apidog verwendet stattdessen CSV/JSON.
    • Properties/Property Transfers: Müssen als Variablen/Umgebungsvariablen neu abgebildet werden.
    • Lasttests via LoadUI Pro: LoadUI Pro-Integration migriert nicht. Lasttests separat (z.B. mit k6) abbilden.

Erstellen Sie eine Tabelle mit Testfallname, Typ (REST/SOAP), Groovy (ja/nein), Komplexität. So schätzen Sie den Migrationsaufwand ab.

Schritt 2: ReadyAPI-Projekt exportieren

Exportieren Sie Ihr Projekt als XML:

  1. In ReadyAPI das Projekt öffnen.
  2. Datei → "Speichern unter" und als XML ablegen.
  3. Externe Datendateien (CSV, Excel, XML) sichern.
  4. Umgebungs-Konfigurationen dokumentieren.

Die XML enthält alle Teststrukturen, Skripte und Konfigurationen.

Schritt 3: API-Definitionen extrahieren

Für REST-APIs empfiehlt sich der Weg über eine OpenAPI-Spezifikation:

  • Option A: In ReadyAPI mit Rechtsklick auf den REST-Dienst → API-Definition exportieren (OpenAPI/Swagger).
  • Option B: OpenAPI-Spezifikation direkt aus dem Backend (z.B. /openapi.json) herunterladen.
  • Option C: Manuell: Alle Endpunkte, Header, Payloads aus ReadyAPI-Anfragen extrahieren.

Schritt 4: Import in Apidog

Importieren Sie die OpenAPI-Spezifikation in Apidog:

  1. Neues Projekt in Apidog anlegen.
  2. APIs → Import → OpenAPI 3.0/Swagger 2.0 auswählen.
  3. Die Datei hochladen oder die URL einfügen.
  4. Apidog generiert daraus die API-Definitionen mit allen Endpunkten.

Postman-Sammlungen: Ebenfalls über Datei → Import → Postman möglich.

Schritt 5: REST-Testfälle neu erstellen

Gehen Sie so vor:

  1. Öffnen Sie einen ReadyAPI REST-Testfall.
  2. Identifizieren Sie: Anfragen, Assertions, Datenquellen.
  3. Erstellen Sie in Apidog einen Testfall zum API-Endpunkt und fügen Sie die Schritte hinzu.

Assertions-Konvertierung:

  • Body enthält String: 
  pm.test('contains value', () => {
    pm.expect(pm.response.text()).to.include('expected string');
  });
Enter fullscreen mode Exit fullscreen mode
  • Statuscode-Check: 
  pm.test('status 200', () => {
    pm.response.to.have.status(200);
  });
Enter fullscreen mode Exit fullscreen mode
  • JSON-Feld prüfen: 
  pm.test('field value', () => {
    pm.expect(pm.response.json().fieldName).to.equal('expected');
  });
Enter fullscreen mode Exit fullscreen mode

Kleine Testfälle ohne Groovy-Skripte sind in 15-30 Minuten migriert.

Schritt 6: Groovy-Skripte nach JavaScript konvertieren

Konvertieren Sie manuell gängige Muster:

Antwortwert lesen:

Groovy:

def response = context.expand('${TestStep#Response}')
def json = new groovy.json.JsonSlurper().parseText(response)
def value = json.fieldName
Enter fullscreen mode Exit fullscreen mode

JavaScript:

const response = pm.response.json();
const value = response.fieldName;
Enter fullscreen mode Exit fullscreen mode

Variable setzen:

Groovy:

testRunner.testCase.setPropertyValue('myVariable', someValue)
Enter fullscreen mode Exit fullscreen mode

JavaScript:

pm.variables.set('myVariable', someValue);
Enter fullscreen mode Exit fullscreen mode

Bedingte Assertion:

Groovy:

if (statusCode == 200) {
  assert responseBody.contains("success")
}
Enter fullscreen mode Exit fullscreen mode

JavaScript:

if (pm.response.code === 200) {
  pm.test('response contains success', () => {
    pm.expect(pm.response.text()).to.include('success');
  });
}
Enter fullscreen mode Exit fullscreen mode

Datumsformat:

Groovy:

def now = new Date()
def formatted = now.format('yyyy-MM-dd')
Enter fullscreen mode Exit fullscreen mode

JavaScript:

const now = new Date();
const formatted = now.toISOString().split('T')[0];
Enter fullscreen mode Exit fullscreen mode

Bei komplexen Skripten: Code sorgfältig analysieren, Logik und Nebenwirkungen verstehen und in JavaScript neu umsetzen. Keine automatische Übersetzung nutzen.

Schritt 7: SOAP-Testfälle behandeln

SOAP-Migration bleibt manuell:

  • Falls REST-Alternative vorhanden: REST-Endpunkte nutzen, SOAP-Schicht eliminieren.
  • Keine REST-Alternative:
    • ReadyAPI für SOAP behalten: Führen Sie ReadyAPI parallel für SOAP-Testfälle weiter und Apidog für REST.
    • SoapUI Open Source: Für grundlegende SOAP-Tests (ohne Lizenzkosten).

WS-Security-Testfälle und komplexe Assertions sind besonders risikobehaftet – Migration nicht überstürzen.

Schritt 8: Umgebungen und Variablen einrichten

  1. In Apidog unter Einstellungen → Umgebungen für jede ReadyAPI-Umgebung eine neue anlegen.
  2. Variablen (Basis-URL, Tokens, Header) übertragen.
  3. Variablen in Testfällen mit {{variableName}} referenzieren.

Schritt 9: CI/CD konfigurieren

Apidog läuft via CLI:

  1. Apidog CLI auf dem Agenten installieren: 
   npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode
  1. Test-Sammlung ausführen: 
   apidog run "path/to/collection.json" -e "environment-id"
Enter fullscreen mode Exit fullscreen mode
  1. Beispiel-Workflow für GitHub Actions: 
   - name: Run API tests
     run: apidog run collection.json --environment staging
Enter fullscreen mode Exit fullscreen mode
  1. In Jenkins: Shell-Schritt mit CLI-Aufruf ergänzen.

Passen Sie Ihre CI-Konfiguration an, entfernen Sie ReadyAPI-testrunner erst, wenn die Apidog-Läufe validiert sind.

Schritt 10: Paralleler Betrieb während der Migration

Betreiben Sie ReadyAPI und Apidog mindestens einen Release-Zyklus parallel:

  • ReadyAPI-Tests bleiben zunächst maßgeblich.
  • Apidog-Tests parallel ausführen und Ergebnisse vergleichen.
  • Alle neuen Testfälle nur noch in Apidog anlegen.
  • Nach Abschluss der Validierung ReadyAPI aus der CI entfernen, aber als Fallback weiter vorhalten.

FAQ

Wie lange dauert die Migration?

Reines REST-Projekt: 1–3 Tage. Großes Projekt mit Groovy und SOAP: 2–6 Wochen. Das Audit aus Schritt 1 gibt eine klare Schätzung.

Werden ReadyAPI-Testdatendateien unterstützt?

CSV funktioniert direkt. Excel erst in CSV konvertieren. XML-Daten ggf. umstrukturieren.

Kann ich beide Tools in derselben CI-Pipeline ausführen?

Ja, empfohlen. Beide Schritte parallel laufen lassen und Ergebnisse vergleichen.

Müssen Umgebungen manuell neu angelegt werden?

Ja, es gibt keinen automatisierten Import. ReadyAPI- und Apidog-Umgebungen nebeneinander öffnen und übertragen.

Was passiert mit Testfällen ohne REST-Äquivalent?

Entweder ReadyAPI (ggf. weniger Lizenzen) behalten, zu SoapUI Open Source migrieren oder Testlücke akzeptieren.

Unterstützt Apidog alle Assertion-Typen von ReadyAPI?

JavaScript-Assertions decken die meisten logischen Bedingungen für REST ab. Spezifische Assertions für SOAP/WS-Security gibt es nicht.

Die Migration von ReadyAPI zu Apidog ist ein strukturiertes Projekt. Mit sorgfältiger Planung, einem klaren Audit, schrittweiser REST-Migration und parallelem Betrieb vermeiden Sie Abdeckungslücken und Regressionen.

Top comments (0)