Warum API-Tests mit Selenium überhaupt zum Thema werden
Drei Gründe, und nur einer davon ist gut.
Die Suite existiert bereits. In der CI gibt es einen Selenium-Job, alle wissen, wie man ihn ausführt, und API-Prüfungen dort zu ergänzen ist der Weg des geringsten Widerstands. Verständlich – aber das ist ein organisatorischer und kein technischer Grund.
Der Ablauf umfasst beides. Ein Formular absenden und anschließend prüfen, ob der von der API angelegte Datensatz korrekt ist. Das ist berechtigt und der Fall, für den sich ein bewusster Entwurf lohnt.
Setup und Teardown. Fixtures über die API anlegen, weil es über die Oberfläche zu langsam ist. Sinnvoll – auch wenn das eher Vorarbeit als Testen ist.
Was es kostet
| Langsames Feedback | Der Browserstart dominiert eine Prüfung, die auch ein Request hätte sein können. Eine Suite, die zwanzig Minuten braucht, wird seltener ausgeführt, und genau das ist der eigentliche Verlust. |
| Unklare Fehlerbilder | Wenn ein kombinierter Test fehlschlägt, müssen Sie erst herausfinden, ob die Oberfläche oder die API defekt ist. Getrennte Suites liefern Ihnen diese Antwort ohne Zusatzaufwand. |
| Vom UI geprägte Abdeckung | Sie decken am Ende die Endpunkte ab, die die Oberfläche zufällig aufruft, und das ist nur ein Bruchteil der Schnittstelle. Fehlercodes und Randparameter werden nie durchlaufen. |
Die Aufteilung, die funktioniert
Setzen Sie Selenium für das ein, was nur ein Browser beantworten kann: Funktioniert der für Nutzer sichtbare Ablauf? Decken Sie die API auf ihrer eigenen Ebene ab, auf der eine Prüfung ein Request ist und kein Seitenaufbau. Nutzen Sie die API aus der Selenium-Suite heraus nur für Setup und Teardown, wo es auf Geschwindigkeit ankommt und keine Assertion im Spiel ist.
Den einen wirklich übergreifenden Fall – ein Formular absenden und prüfen, was das Backend gespeichert hat – schreiben Sie besser bewusst als zufällig. Es sind wenige Tests, und sie rechtfertigen ihren Aufwand.
Was eine eigenständige API-Ebene abdecken muss
Vier Dinge entscheiden darüber, ob eine API-Suite ihr erstes Jahr übersteht, unabhängig vom eingesetzten Werkzeug: Sessions, die ablaufen, Werte, die erst zur Laufzeit existieren, Aufrufe, die voneinander abhängen, und Datensätze, die niemand aufräumt. TestSprite nennt das Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup, und die Dokumentation zu API-Tests erklärt die Mechanik dahinter.
Ob Sie diese vier Punkte in den Griff bekommen, entscheidet darüber, ob eine Suite Bestand hat oder nach zwei Quartalen gelöscht wird, und auf API-Ebene gelingt das deutlich leichter als angeflanscht an eine Browser-Suite.
Der Setup-Fall, richtig gemacht
Fixtures für einen Browser-Test über die API anzulegen, ist die eine Stelle, an der beide wirklich zusammengehören, und dort lohnt es sich, bewusst statt zufällig vorzugehen.
Sauber bleibt das durch eine Regel: Setup-Aufrufe enthalten niemals Assertions. Ihre Aufgabe ist es, das System so schnell wie möglich in einen bekannten Zustand zu bringen, und schlägt einer davon fehl, sollte der Test als Error abbrechen statt als Failure zu gelten, denn ein misslungenes Fixture ist ein Infrastrukturproblem und kein Produktdefekt. Wer beides vermischt, bekommt eine Suite, in der die Hälfte des Rots nur Rauschen ist.
Die zweite Regel lautet: Was das Setup angelegt hat, entfernt das Teardown, gebunden an den jeweiligen Test und nicht über einen Namensabgleich. Browser-Suites sammeln schneller Daten an, als alle erwarten, und eine Listenansicht, die jede Woche langsamer wird, ist meist ein Teardown, das nie geschrieben wurde.
Beides betreiben
Keine der beiden Suites muss von der anderen wissen. Selenium läuft wie bisher in Ihrem CI-Job, und die API-Abdeckung läuft daneben.
Wenn die Pipeline einem anderen Team gehört, ist die GitHub App der Weg des geringsten Widerstands: Sie ist ein Webhook, ändert nichts an Ihrem Repository und wird ausgelöst, sobald Ihr Build die neue Version als live meldet. Wenn Sie die Prüfung stattdessen im Repository sichtbar haben möchten, leistet das ein GitHub Actions -Schritt. Siehe das CLI-Repository.
Was TestSprite auf API-Ebene abdeckt
TestSprite übernimmt die eigenständige API-Ebene, sodass Sie sie nicht an eine Browser-Suite anflanschen müssen. API Discovery ermittelt, was der laufende Dienst bereitstellt, Plan Generation schlägt Testfälle über die Kategorien Funktionalität, Schema, Autorisierung, Fehlerbehandlung und Grenzwerte hinweg vor, und Sie verfeinern sie in natürlicher Sprache.
Die vier Zustandsprobleme kommen als Produkt und nicht als Ihre eigene Infrastruktur: Auto-Authentication hält Sessions am Leben, Dynamic Variables tragen Werte von Aufruf zu Aufruf, Dependency Chains leiten die Ausführungsreihenfolge ab, Auto-Cleanup entfernt, was ein Lauf erzeugt hat. Genau das macht es schwer, eine API-Suite am Leben zu halten, und auf API-Ebene lässt es sich deutlich leichter lösen als in einem Browser-Runner.
Ihre Selenium-Suite bleibt, wo sie ist, und deckt ab, was nur ein Browser beantworten kann. Beide laufen aus derselben Pipeline.
Kann Selenium HTTP-Requests direkt senden?
Über die Sprach-Bindings ja, denn Sie schreiben dort schlicht Code. Die Frage ist, ob überhaupt eine Browser-Session beteiligt sein sollte, und bei einer reinen API-Prüfung lautet die Antwort meist Nein.
Sollten wir unsere Selenium-Suite migrieren?
Nicht pauschal. Eine Selenium-Suite, der das Team vertraut, ist ein Wert an sich. Ergänzen Sie die API-Abdeckung auf ihrer eigenen Ebene, statt etwas zu verschieben.
Wie testen wir einen Ablauf, der beides umfasst?
Schreiben Sie ihn bewusst als einen Test, halten Sie die Anzahl klein und formulieren Sie die Assertion so genau, dass ein Fehlschlag zeigt, welche Seite defekt ist.
Ist Playwright dafür besser geeignet?
Es bringt eine vollwertige Request-API mit, die Umsetzung ist damit angenehmer. Am architektonischen Argument ändert das nichts: Browser-Prüfungen und API-Prüfungen beantworten unterschiedliche Fragen und bleiben besser getrennt.
Wie steht es mit der Authentifizierung über beide hinweg?
Teilen Sie die Quelle der Zugangsdaten, nicht die Session. Jede Ebene sollte sich ihre eigene Session holen, damit ein Fehler in der einen nicht auf die andere durchschlägt.
Nutzen Sie den Browser für Browser-Fragen.
API-Tests mit Selenium bedeuten meist, zwei Arten von Prüfungen zu koordinieren, statt ein Werkzeug zu beidem zu zwingen. Behalten Sie Selenium für die für Nutzer sichtbaren Abläufe, decken Sie die API auf ihrer eigenen Ebene ab und schreiben Sie die wirklich übergreifenden Tests ganz bewusst.