REST-Assured Tutorial 2026: API-Tests in Java richtig planen

Sie sollen eine REST-Schnittstelle automatisiert testen und Ihr Team arbeitet ohnehin in Java? Dann stellt sich schnell die Frage nach dem richtigen Werkzeug. REST-Assured hat sich als Standard für API-Tests (Schnittstellentest) in der Java-Welt etabliert, weil es HTTP-Aufrufe und Prüfungen in einer lesbaren given/when/then-Notation ausdrückt.

Dieser Praxis-Guide zeigt Ihnen, wie Sie REST-Assured aufsetzen, aussagekräftige Assertions schreiben und die Tests in Ihre CI/CD-Pipeline bringen. Wichtiger noch: Wir ordnen das Werkzeug in eine belastbare Gesamt-Teststrategie ein, verbinden es mit Ihrem Testmanagement und zeigen, wo KI heute konkret unterstützt.

Denn ein Werkzeug allein macht keine gute Qualität. Erst die Einbettung in Strategie, Testmanagement und ein sauberes Testdatenkonzept macht aus API-Tests einen echten Beitrag zur Produktqualität.

Was ist REST-Assured und wann lohnt es sich?

REST-Assured ist eine quelloffene Java-Bibliothek für den automatisierten API-Test (englisch: API testing). Sie bringt die Lesbarkeit dynamischer Sprachen in die Java-Welt und beschreibt einen Testfall in drei Schritten: Vorbedingung (given), Aktion (when) und Prüfung (then). Die aktuelle Version ist laut rest-assured.io die 6.0.1.

REST-Assured lohnt sich, wenn Ihre Anwendung ohnehin auf der JVM läuft, Ihr Team Java oder Kotlin beherrscht und die API-Tests eng mit Unit- und Integrationstests im selben Build laufen sollen. Für rein manuelle, explorative Prüfungen greifen Tester eher zu einem grafischen Client wie Postman oder Bruno. REST-Assured spielt seine Stärke dort aus, wo Tests versioniert, reproduzierbar und Teil der Pipeline sein müssen.

Wann ein anderes Werkzeug besser passt

Arbeitet Ihr Team ohne Java-Kenntnisse, ist Karate die naheliegende Alternative, weil die Tests dort in Gherkin geschrieben werden. Einen vollständigen Überblick über die Werkzeuglandschaft gibt unser Artikel API Testing Tools im Vergleich.

Setup: Maven- und Gradle-Dependency

REST-Assured wird als Test-Dependency eingebunden. Für aussagekräftige Prüfungen ergänzen Sie den JSON-Schema-Validator und den JSON-Path. Die folgende Tabelle zeigt die zentralen Koordinaten.

Nach dem Einbinden importieren Sie die statischen Methoden, damit die given/when/then-Notation lesbar bleibt. Ein Test-Runner wie JUnit 5 oder TestNG steuert die Ausführung.

import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;
import static org.hamcrest.Matchers.hasItems;

Der erste Test: given, when, then

Der Aufbau eines REST-Assured-Tests folgt immer demselben Muster. Sie definieren die Vorbedingungen, senden die Anfrage und prüfen die Antwort. Das folgende Beispiel prüft einen GET-Aufruf gegen eine öffentliche Test-API.

@Test
void lottoResourceLiefertErwarteteIds() {
    given()
        .baseUri("https://api.example.com")
    .when()
        .get("/lotto")
    .then()
        .statusCode(200)
        .body("lotto.lottoId", equalTo(5))
        .body("lotto.winners.winnerId", hasItems(23, 54));
}

Der Reiz liegt in der Lesbarkeit: Auch ein Test Manager ohne tiefe Java-Kenntnisse erkennt, was geprüft wird. Diese fachliche Nachvollziehbarkeit ist entscheidend, wenn Testfälle als Nachweis in einer Ausschreibung oder einem Audit dienen.

Assertions, JSON-Path und Schema-Validierung

REST-Assured prüft Antworten auf drei Ebenen: einzelne Felder über JSON-Path, ganze Strukturen über eine JSON-Schema-Validierung und technische Merkmale wie Statuscode, Header und Antwortzeit. Die Schema-Validierung ist besonders wertvoll, weil sie einen Vertragsbruch der Schnittstelle erkennt, ohne dass Sie jedes Feld einzeln prüfen.

given()
    .accept("application/json")
.when()
    .get("/products/42")
.then()
    .statusCode(200)
    .time(lessThan(800L))
    .body("name", equalTo("Testprodukt"))
    .body(matchesJsonSchemaInClasspath("product-schema.json"));

Die Antwortzeit-Prüfung (time(lessThan(...))) verankert ein einfaches Performance-Kriterium direkt im funktionalen Test. Für echte Lasttests bleibt ein spezialisiertes Werkzeug notwendig, doch eine grobe Antwortzeit-Schwelle gehört in jeden API-Test.

Authentifizierung: Basic, Bearer und OAuth 2

Reale Schnittstellen verlangen fast immer eine Authentifizierung. REST-Assured unterstützt Basic Auth, Bearer-Token und OAuth 2 direkt. In der Praxis holen Sie das Token einmal in einem Vorbereitungsschritt und verwenden es in den folgenden Aufrufen weiter.

String token = holeAccessToken();

given()
    .auth().oauth2(token)
    .contentType("application/json")
    .body(neueBestellung)
.when()
    .post("/orders")
.then()
    .statusCode(201)
    .header("Location", containsString("/orders/"));

Wichtig aus Sicherheitssicht: Token und Zugangsdaten gehören nie in den Quellcode oder in Log-Ausgaben. Nutzen Sie Umgebungsvariablen oder einen Secret-Store der Pipeline. Ein API-Test, der Secrets im Klartext protokolliert, wird schnell selbst zum Risiko.

Datengetriebene Tests und Reporting

Ein datengetriebener Test (englisch: data-driven testing) führt denselben Ablauf mit vielen Eingabekombinationen aus. Mit JUnit 5 gelingt das über eine parametrisierte Testmethode. So decken Sie Grenzwerte, ungültige Eingaben und Negativfälle systematisch ab, ohne den Testcode zu vervielfachen.

@ParameterizedTest
@ValueSource(strings = {"", "   ", "??", "a".repeat(300)})
void ungueltigeNamenWerdenAbgelehnt(String name) {
    given()
        .contentType("application/json")
        .body(Map.of("name", name))
    .when()
        .post("/products")
    .then()
        .statusCode(400);
}

Für die Auswertung koppeln viele Teams REST-Assured mit einem Reporting-Werkzeug wie Serenity BDD oder Allure. Das erzeugt einen lesbaren Bericht mit Anfrage, Antwort und Prüfergebnis, den auch fachliche Stakeholder verstehen. Negative Testfälle sind dabei Pflicht: Ein Testsatz, der nur den Gutfall prüft, übersieht genau die Fehler, die in Produktion teuer werden.

CI/CD-Integration

Ihren vollen Wert entfalten API-Tests erst in der Pipeline. REST-Assured-Tests laufen über den Maven-Surefire- oder Failsafe-Plugin-Lauf und melden Fehler direkt im Build. Das folgende Beispiel zeigt einen minimalen Ablauf in GitHub Actions.

name: api-tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "21"
      - run: mvn -B test
        env:
          API_TOKEN: ${{ secrets.API_TOKEN }}

Qualität ist kein Gate am Ende der Pipeline. Qualität ist die Pipeline. Wer API-Tests nur nachts oder von Hand laufen lässt, verschenkt ihren wichtigsten Nutzen: die schnelle Rückmeldung bei jedem Commit.

REST-Assured in der Gesamt-Teststrategie

Ein Werkzeug ist nur so gut wie die Strategie dahinter. In der Testpyramide sitzen API-Tests in der mittleren Schicht: schneller und stabiler als Tests über die Oberfläche, aber näher an der Fachlichkeit als reine Unit-Tests. Genau hier liefert REST-Assured das beste Verhältnis aus Aufwand und Aussagekraft.

Eine belastbare Strategie klärt vor der ersten Zeile Code drei Fragen: Welche Schnittstellen sind geschäftskritisch und werden zuerst abgedeckt? Wo grenzen sich API-Tests von Contract-Tests und von Oberflächentests ab? Und welches Testdatenkonzept sorgt dafür, dass Tests reproduzierbar bleiben? Ohne diese Klärung entsteht schnell eine große, aber wenig aussagekräftige Testsuite.

Die Abgrenzung ist wichtig: Ein API-Test prüft das Verhalten eines Endpunkts. Ein Contract-Test prüft, ob zwei Dienste dieselbe Annahme über die Schnittstelle teilen. Ein Oberflächentest prüft den Weg des Anwenders. Erst zusammen ergeben sie eine sinnvolle Abdeckung. Wie eine solche Strategie entsteht, beschreibt unser Artikel zum Vergleich der API-Testing-Tools im Kontext der gesamten Werkzeugkette.

Integration ins Testmanagement

API-Tests entfalten ihren Wert für Entscheider erst, wenn sich ihre Ergebnisse im Testmanagement wiederfinden. Der Standardweg führt über den JUnit-XML-Report, den nahezu jedes Testmanagement-Werkzeug importiert. So entsteht eine durchgängige Nachvollziehbarkeit von der Anforderung über den Testfall bis zum Ergebnis.

Entscheidend ist nicht das konkrete Werkzeug, sondern die durchgängige Rückverfolgbarkeit. Jeder automatisierte Testfall sollte auf eine Anforderung verweisen, und jedes Testergebnis sollte im Managementbericht sichtbar sein. Erst diese Verbindung macht aus grünen Balken eine belastbare Aussage über Produktqualität. Wer sein Testmanagement in Jira und Xray aufbaut, findet in unserem Testautomatisierungs-Angebot die passende Beratung.

KI-gestütztes API-Testing mit REST-Assured

REST-Assured selbst enthält keine KI-Funktionen. Der Hebel liegt im Prozess drumherum: Ein Sprachmodell beschleunigt die Arbeiten vor und nach dem eigentlichen Test. Drei Anwendungen haben sich in der Praxis bewährt.

Erstens die Testfall-Ableitung: Aus einer OpenAPI-Spezifikation lässt ein Modell Vorschläge für Gut- und Fehlerfälle generieren, die Sie als Grundgerüst übernehmen und fachlich schärfen. Zweitens die Testdaten-Erzeugung: Grenzwerte, ungültige Eingaben und realistische Datensätze entstehen schneller. Drittens die Schema-Ableitung: Ein Modell erstellt aus Beispielantworten einen ersten Entwurf des JSON-Schemas für die Vertragsprüfung.

Wichtig ist die fachliche Kontrolle. Ein generierter Testfall ist ein Vorschlag, kein fertiger Nachweis. Die Bewertung von Risiko, Priorität und Testtiefe bleibt Aufgabe des Testers. Genau diese Kombination aus Werkzeug und Urteil ordnet der ISTQB-Lehrplan Certified Tester AI Testing (CT-AI) ein, der den verantwortungsvollen Einsatz von KI im Test beschreibt.

KI ersetzt keine Tester. Sie ersetzt Tester, die keine KI nutzen. Wer die Werkzeuge kennt und ihr Ergebnis kritisch prüft, gewinnt Tempo, ohne die Kontrolle abzugeben.

Stolperfallen

Drei Fehler sehen wir in Projekten immer wieder. Erstens: Tests, die nur den Gutfall prüfen. Ohne Negativfälle bleibt die eigentliche Schwachstelle unentdeckt. Zweitens: harte Abhängigkeiten von realen Fremdsystemen. Wenn ein Test von einer instabilen Drittanbieter-API abhängt, wird er unzuverlässig und verliert an Vertrauen. Drittens: Secrets im Klartext, etwa im Log der Pipeline.

Ein vierter, subtiler Fehler ist die fehlende Verbindung zur Anforderung. Eine große Testsuite ohne Rückverfolgbarkeit sieht beeindruckend aus, sagt aber wenig über die abgedeckten Risiken. Beginnen Sie mit den geschäftskritischen Schnittstellen und verknüpfen Sie jeden Test mit seiner Anforderung.

Fazit: REST-Assured ist stark, die Strategie entscheidet

REST-Assured ist das ausgereifte Standardwerkzeug für API-Tests in Java. Seine lesbare given/when/then-Notation, die Schema-Validierung und die nahtlose CI/CD-Integration machen es zur ersten Wahl für Teams auf der JVM.

Tools wechseln. Qualitätsdenken bleibt. Der eigentliche Wert entsteht, wenn Sie REST-Assured in eine klare Teststrategie einbetten, die Ergebnisse ins Testmanagement zurückspielen und KI dort einsetzen, wo sie den Tester entlastet statt ersetzt.

Wenn Sie API-Tests aufbauen oder eine bestehende Suite konsolidieren wollen, unterstützen wir Sie von der Strategie bis zur Pipeline.

Häufige Fragen zu REST-Assured (FAQ)

Ist REST-Assured kostenlos?

Ja. REST-Assured ist eine quelloffene Bibliothek und kostenlos nutzbar, auch im kommerziellen Umfeld. Es fallen keine Lizenzkosten an, lediglich der Aufwand für Einrichtung und Pflege der Tests.

Brauche ich Java-Kenntnisse für REST-Assured?

Ja. REST-Assured ist eine Java-Bibliothek, die Tests werden in Java oder Kotlin geschrieben. Wer ohne Programmierkenntnisse API-Tests aufbauen möchte, ist mit Karate oder einem grafischen Client wie Postman besser bedient.

REST-Assured oder Karate: Was ist besser?

Das hängt vom Team ab. REST-Assured passt zu Java-Teams, die Tests eng mit dem Code führen. Karate passt zu Teams ohne Java-Fokus, weil die Tests in Gherkin geschrieben werden. Beide sind quelloffen und für den professionellen Einsatz geeignet.

Kann REST-Assured in CI/CD-Pipelines laufen?

Ja. Die Tests laufen über den Maven- oder Gradle-Build und lassen sich in jede Pipeline einbinden, etwa GitHub Actions, GitLab CI oder Jenkins. Die Ergebnisse liegen als JUnit-XML vor und wandern von dort ins Testmanagement.

Wie unterstützt KI beim API-Testing mit REST-Assured?

KI hilft vor allem bei der Vorbereitung: Testfall-Vorschläge aus der OpenAPI-Spezifikation, Testdaten-Erzeugung und ein erster Entwurf des JSON-Schemas. Die fachliche Bewertung und die Auswahl der Testtiefe bleiben Aufgabe des Testers.

Wo sitzen API-Tests in der Teststrategie?

API-Tests sitzen in der mittleren Schicht der Testpyramide. Sie sind schneller und stabiler als Oberflächentests und näher an der Fachlichkeit als Unit-Tests. Sie ersetzen weder Contract-Tests noch Oberflächentests, sondern ergänzen sie.