Selenium für API Tests: Sinnvoll oder nicht?

Selenium ist ein Framework zur Browserautomatisierung. Es steuert Chrome, Firefox und andere Browser so, wie es ein Mensch tun würde: Schaltflächen anklicken, Formulare ausfüllen, die gerenderte Seite lesen. Es ist das Standardwerkzeug für End-to-End-UI-Tests und erfüllt diese Aufgabe sehr gut.

Es wird immer noch gefragt, ob Selenium APIs testen kann. Die ehrliche Antwort ist, dass man es dazu bringen kann, HTTP-Aufrufe auszuführen, aber es ist das falsche Werkzeug für diese Arbeit. Dieser Leitfaden erklärt genau, warum, zeigt, wie API-Tests mit Selenium tatsächlich aussehen, und weist auf Tools hin, die für diese Aufgabe entwickelt wurden. Ziel ist es, Sie vor einer Einrichtung zu bewahren, die Sie später frustrieren wird.

Warum Selenium und API-Tests nicht zusammenpassen

Ein API-Test sendet eine HTTP-Anfrage direkt an einen Server und prüft die Antwort: Statuscode, Header, Body, Timing. Es ist keine Benutzeroberfläche beteiligt. Der Test sollte schnell, isoliert und kostengünstig sein, um Tausende Male ausgeführt zu werden.

Selenium tut das Gegenteil, und das ist beabsichtigt. Es startet einen echten Browser, lädt Seiten und wartet darauf, dass JavaScript gerendert wird. Dieser Browser ist der ganze Sinn, wenn Sie eine Benutzeroberfläche testen, und er ist reiner Overhead, wenn Sie eine API testen. Eine Anfrage, die ein dedizierter Client in zehn Millisekunden sendet, wird zu einer Angelegenheit von mehreren Sekunden, sobald Sie einen Browserprozess, eine WebDriver-Sitzung und das Rendern der Seite einbeziehen.

Es gibt auch eine tiefere Diskrepanz. Die gesamte API von Selenium dreht sich um Elemente auf einer Seite: diesen Button finden, diesen Text lesen, auf dieses Element warten. Eine HTTP-Antwort ist keine Seite. Sie hat kein DOM. Selenium bietet Ihnen also nichts Nützliches zur Überprüfung eines JSON-Bodys, zur Bestätigung eines Headers oder zur Überprüfung eines Statuscodes. Sie arbeiten am Ende um das Tool herum, anstatt damit.

Die Kosten sind nicht nur die Geschwindigkeit. Browserbasierte Tests sind bekanntermaßen fehleranfällig. Sie scheitern, weil eine Seite einen Moment länger zum Rendern brauchte, weil eine WebDriver-Sitzung abgebrochen wurde oder weil ein Browser-Update das Timing geändert hat. Ein API-Test sollte deterministisch sein: Dieselbe Anfrage erzeugt dieselbe Antwort, und ein Fehler bedeutet, dass tatsächlich etwas kaputt ist. Das Routing von API-Prüfungen über Selenium überträgt all diese Browser-Flakiness in eine Schicht, die überhaupt keinen Grund hätte, fehleranfällig zu sein. Im Laufe der Zeit führt eine fehleranfällige Suite dazu, dass das Team rote Builds achselzuckend hinnimmt, was den Sinn des Testens zunichtemacht. Die Unterscheidung zwischen Validierung und Verifikation ist hier eine gute Betrachtungsweise: Selenium verifiziert die gerenderte Erfahrung, während API-Tests den darunter liegenden Vertrag validieren.

Was „API-Tests mit Selenium“ tatsächlich bedeutet

Wenn Artikel behaupten, Selenium könne APIs testen, meinen sie normalerweise eine von zwei Umgehungslösungen. Keine davon macht Selenium zu einem API-Testwerkzeug. Sie leiten HTTP lediglich durch oder neben Selenium.

Option eins: Verwenden Sie den JavaScript-Executor von Selenium. Selenium kann beliebigen JavaScript-Code in dem von ihm gesteuerten Browser ausführen. Moderne Browser verfügen über die fetch-API, sodass Sie den Browser anweisen können, eine Anfrage zu stellen und das Ergebnis an Ihren Testcode zurückzugeben:

JavascriptExecutor js = (JavascriptExecutor) driver;
Object status = js.executeAsyncScript(
    "const callback = arguments[arguments.length - 1];" +
    "fetch('https://jsonplaceholder.typicode.com/users/1')" +
    "  .then(r => callback(r.status))" +
    "  .catch(e => callback('error: ' + e));"
);
System.out.println("Status code: " + status);

Das funktioniert. Es bedeutet aber auch, dass Sie einen Browser, einen WebDriver und eine JavaScript-Brücke gestartet haben, nur um einen HTTP-Aufruf zu tätigen, den ein normaler HTTP-Client direkt machen würde. Sie erben auch Browserbeschränkungen wie CORS, über die sich ein Server-zu-Server-API-Test nie Gedanken machen muss.

Option zwei: Ignorieren Sie Selenium und verwenden Sie daneben eine echte HTTP-Bibliothek. In einem Java-Projekt bedeutet dies, Selenium mit REST Assured für die API-Teile zu koppeln:

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

given()
    .when()
    .get("https://jsonplaceholder.typicode.com/users/1")
    .then()
    .statusCode(200)
    .body("email", equalTo("Sincere@april.biz"));

Beachten Sie, dass die eigentlichen API-Tests hier vollständig von REST Assured durchgeführt werden. Selenium trägt nichts dazu bei. Die beiden Bibliotheken befinden sich zufällig im selben Projekt. Das ist in Ordnung, aber es ist kein „API-Testen mit Selenium“. Es ist API-Testen mit einer geeigneten API-Testbibliothek, wobei Selenium für unabhängige UI-Tests vorhanden ist.

Wann das Mischen sinnvoll ist

Es gibt einen legitimen Anwendungsfall für HTTP-Arbeit innerhalb einer Selenium-Suite, und es lohnt sich, dies klarzustellen. Selenium UI-Tests benötigen oft eine Einrichtung oder Aufräumarbeiten, die über die API schneller zu erledigen sind als über den Browser.

Angenommen, Sie haben einen UI-Test, der die Bestellhistorie-Seite überprüft. Um diese zu testen, muss eine Bestellung existieren. Das Durchklicken des gesamten Checkout-Flows im Browser, nur um diese Bestellung zu erstellen, ist langsam und anfällig. Stattdessen tätigt Ihr Test einen direkten API-Aufruf, um die Bestellung zu erstellen, und verwendet Selenium dann nur für den Teil, der wirklich einen Browser benötigt: das Laden der Historie-Seite und die Überprüfung, ob die Bestellung angezeigt wird.

Das ist eine gute Praxis. Der API-Aufruf ist ein Mittel zum Zweck, nicht die zu testende Sache. Der API-Aufruf sollte immer noch über einen echten HTTP-Client erfolgen, nicht über den JavaScript-Executor. Auch in diesem Fall führt Selenium also nicht die API-Tests durch. Es führt die UI-Tests durch, und ein geeigneter HTTP-Client übernimmt die API-Seite.

Dieses „Setup-über-API“-Muster ist so verbreitet, dass die meisten ausgereiften Test-Suites es bewusst übernehmen. Es hält den langsamen, browsergesteuerten Teil der Suite so klein wie möglich, reserviert für die wenigen Journeys, die wirklich eine gerenderte Seite benötigen. Alles andere, einschließlich der gesamten Datenvorbereitung und der meisten Verifikationen, geschieht über schnelle HTTP-Aufrufe. Das Ergebnis ist eine Suite, die in Minuten statt Stunden läuft und nur aus echten Gründen fehlschlägt. Für ein breiteres Bild, wie UI- und automatisierte Schichten zusammenpassen, siehe funktionale Tests versus automatisierte Tests.

Verwenden Sie ein Tool, das für API-Tests entwickelt wurde

Wenn Ihr Ziel darin besteht, APIs zu testen, verwenden Sie etwas, das dafür konzipiert ist. Der Unterschied ist nicht gering. Ein echtes API-Testtool bietet Ihnen die Erstellung von Anfragen, Umgebungsverwaltung, Zusicherungen für Status, Header und Body, Request-Verkettung, datengesteuerte Ausführungen und CI-Integration, ohne einen Browser zu starten.

Ihre Optionen lassen sich in einige Gruppen einteilen:

Wenn Sie Code bevorzugen, ist eine HTTP-Bibliothek wie REST Assured in Java, requests in Python oder supertest in Node die richtige Wahl. Diese Bibliotheken senden eine Anfrage und geben Ihnen die Antwort direkt zurück, mit integrierten Assertions-Helfern für Statuscodes und JSON-Bodies. Es gibt keinen Browser, keinen WebDriver und kein Rendering, sodass eine vollständige Suite schnell läuft und nur fehlschlägt, wenn sich die API selbst ändert.

Wenn Sie einen visuellen Arbeitsbereich wünschen, ist Apidog eine All-in-One-API-Plattform, die das Design der API, das Debuggen von Anfragen, das Mocking von Endpunkten, das Erstellen automatisierter Testszenarien und die Generierung von Dokumentationen in einem einzigen Projekt abdeckt. Sie erstellen Assertions visuell oder mit Skripten, verketten Anfragen zu mehrstufigen Abläufen, führen datengesteuerte Iterationen durch und führen alles in CI aus. Es importiert auch OpenAPI- und Postman-Dateien, sodass eine bestehende API schnell integriert werden kann. Nichts davon beinhaltet einen Browser, weil nichts davon einen Browser beinhalten sollte. Sie können Apidog herunterladen, um es an einer realen API auszuprobieren.

Für Teams, die ein codezentriertes Framework wünschen, behandeln die Anleitungen zu Robot Framework für die API-Automatisierung und dem Aufbau eines API-Automatisierungstest-Frameworks Ansätze, die, anders als Selenium, tatsächlich für HTTP-Tests geeignet sind.

Das ehrliche Fazit

Selenium ist eine ausgezeichnete Software für das, wofür sie entwickelt wurde, nämlich Browser zu automatisieren. API-Tests gehören nicht dazu. Sie können HTTP technisch über den JavaScript-Executor von Selenium pushen, und Sie können eine HTTP-Bibliothek im selben Projekt wie Selenium behalten, aber in keinem Fall trägt Selenium einen Mehrwert zu den API-Tests selbst bei.

Die Wahl des falschen Werkzeugs ist keine neutrale Entscheidung. Sie macht Ihre Tests langsamer, wartungsaufwändiger und anfälliger für Fehler, die nichts mit Ihrer API zu tun haben. Greifen Sie zu einem Tool, das für die Aufgabe entwickelt wurde. Ihre Testsuite wird schneller, zuverlässiger und viel einfacher nachvollziehbar sein. Die Zusammenstellung der besten automatisierten Testplattformen ist ein guter Ausgangspunkt, um speziell entwickelte Optionen zu vergleichen.

Häufig gestellte Fragen

Kann Selenium überhaupt REST-APIs testen?

Es kann HTTP-Anfragen über den JavaScript-Executor des Browsers senden, also in einem engen technischen Sinne ja. Aber Selenium hat keine Funktionen zur Überprüfung von Antworten, zur Bestätigung von JSON oder zur Überprüfung von Headern, und es trägt den gesamten Overhead eines Browsers. Es ist kein REST-API-Testwerkzeug, und seine Verwendung als solches führt zu langsamen, fragilen Tests.

Warum zeigen einige Tutorials Selenium mit REST Assured?

Weil die API-Tests in diesen Tutorials vollständig von REST Assured durchgeführt werden, einer echten HTTP-Testbibliothek. Selenium ist nur im selben Projekt für unabhängige UI-Tests vorhanden. Die Kombination ist in Ordnung, aber es bedeutet nicht, dass Selenium die API testet. REST Assured tut es.

Ist es jemals in Ordnung, API-Aufrufe in einem Selenium-Test zu machen?

Ja, für Setup und Teardown. Das Erstellen von Testdaten über die API ist schneller und zuverlässiger, als sie durch Klicken auf der Benutzeroberfläche zu erzeugen. Der API-Aufruf unterstützt den UI-Test, anstatt das zu testende Element zu sein, und er sollte immer noch einen geeigneten HTTP-Client verwenden, nicht den JavaScript-Executor von Selenium.

Was sollte ich anstelle von Selenium für API-Tests verwenden?

Für code-first Tests eine HTTP-Bibliothek wie REST Assured, Pythons requests oder supertest für Node. Für einen visuellen Arbeitsbereich eine dedizierte API-Plattform wie Apidog oder Clients wie Postman, Insomnia und Talend API Tester. All diese sind für HTTP entwickelt und vermeiden den Browser-Overhead, den Selenium auferlegt.

Verlangsamt die Verwendung von Selenium für API-Tests meine CI-Pipeline?

Deutlich. Jeder Selenium-basierte API-Aufruf startet einen Browserprozess und eine WebDriver-Sitzung, wodurch eine HTTP-Anfrage, die weniger als eine Sekunde dauert, zu einem Vorgang von mehreren Sekunden wird. Über eine Suite hinweg summiert sich das zu langen, fehleranfälligen Pipeline-Läufen. Ein dediziertes API-Testwerkzeug führt dieselben Prüfungen viel schneller aus, da es nie einen Browser startet.