REST-API-Testing beginnt bei der Semantik der Statuscodes
REST weist Statuscodes eine Bedeutung zu, und Clients verlassen sich darauf. Diese Bedeutung sollten Sie explizit prüfen, statt sie vorauszusetzen.
201 mit Location beim Anlegen, nicht 200 mit einem Body und sonst nichts.
404 für nicht vorhanden, 403 für nicht erlaubt. 404 statt 403 zurückzugeben ist eine bewusste Entscheidung, die manche Teams treffen; 403 für eine nicht vorhandene Ressource ist schlicht ein Bug.
422 oder 400 bei ungültigen Eingaben, und zwar einheitlich. Entscheiden Sie sich für eines und prüfen Sie, dass jeder Endpunkt sich daran hält.
Niemals 200 mit einem Fehler im Body. Kommt häufig vor und zwingt jeden Client zu einer Sonderbehandlung.
Idempotenz
PUT und DELETE sollen idempotent sein. Ein zweiter Aufruf muss denselben Zustand hinterlassen und darf beim zweiten Mal keinen Fehler auslösen. Das geht leicht schief und lässt sich leicht prüfen: zweimal aufrufen und verifizieren.
Dasselbe gilt dafür, dass ein zweites DELETE 404 statt 500 zurückgibt. Clients wiederholen Anfragen, und ein Endpunkt, der Wiederholungen nicht verträgt, macht aus einem kurzen Netzwerkaussetzer einen für Nutzer sichtbaren Fehler.
Die Konventionen, zu denen sich Ihr Service bekennt
| Paginierung | Liefert ein vollständiger Durchlauf die Anzahl, die die Collection angibt. Off-by-one-Fehler an Seitengrenzen sind ausgesprochen häufig. |
| Filtern und Sortieren | Wird ein unbekannter Filter abgelehnt oder stillschweigend ignoriert. Stillschweigendes Ignorieren liefert Daten, die mit voller Überzeugung falsch sind. |
| Partielles Update | Ändert PATCH nur das, was gesendet wurde, oder setzt es den Rest klammheimlich auf null. |
Die Prüfung, die unter all dem liegt
Prüfen Sie den Body, nicht nur den Status. Eine 200 mit einer leeren Liste dort, wo ein Datensatz stehen müsste, besteht jede Status-Assertion, die je geschrieben wurde. Diese eine Gewohnheit deckt beim REST-API-Testing mehr echte Defekte auf als jede Konventionsprüfung.
Die vier Probleme
Vier Dinge entscheiden darüber, ob eine API-Suite ihr erstes Jahr übersteht: Sessions, die ablaufen, Werte, die es nur zur Laufzeit gibt, Aufrufe, die voneinander abhängen, und Datensätze, die niemand aufräumt. TestSprite deckt diese Punkte mit Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup ab, beschrieben in der Dokumentation zum API-Testing.
Die Konventionen, die Sie zuerst festhalten sollten
Bevor Sie prüfen können, ob Ihre API ihren Konventionen folgt, muss jemand festlegen, welche das sind – und die meisten Teams stellen dabei fest, dass sie sich uneinig sind.
Vier Fragen klären das meiste davon. Welchen Status gibt ein Erzeugen zurück, und enthält die Antwort eine Location. Ist eine fehlende Ressource eine 404 oder eine 403, wenn der Aufrufer sie ohnehin nicht sehen dürfte. Wird ein unbekannter Query-Parameter abgelehnt oder ignoriert. Behandelt PATCH ein fehlendes Feld als unverändert oder als null.
Für keine dieser Fragen gibt es eine allgemeingültig richtige Antwort, und jede einzelne ist eine Entscheidung, auf die sich Ihre Clients verlassen. Die vier Antworten aufzuschreiben dauert zwanzig Minuten und macht aus der vagen Absicht, RESTful zu sein, etwas, das Sie tatsächlich prüfen können – und das ist die Voraussetzung dafür, dass überhaupt etwas davon getestet wird.
Abdeckung erreichen, ohne alles selbst zu schreiben
Generierte Pläne decken die Kategorien Funktionalität, Schema, Autorisierung, Fehlerbehandlung und Grenzfälle ab – ausgehend von einer Spezifikation oder einem Discovery-Durchlauf. Damit sind die meisten der oben genannten Konventionsprüfungen standardmäßig enthalten.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Wenn Sie nichts installieren möchten, erledigt das Dashboard dasselbe. Alles Weitere, was die Kommandozeile kann, finden Sie im CLI-Repository.
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 die Prüfung stattdessen im Repository sichtbar sein soll, erledigt das ein GitHub Actions -Schritt.
Wie TestSprite die Konventionen prüft
Generierte Pläne decken die Kategorien Funktionalität, Schema, Autorisierung, Fehlerbehandlung und Grenzfälle gegen den laufenden Service ab. Darin stecken die meisten der oben genannten Konventionsprüfungen: Status-Semantik pro Operation, Ablehnung ungültiger Eingaben, Verhalten bei einer fehlenden Ressource und eine Paginierung, deren Zahlen aufgehen.
Auto-Authentication hält Sessions über einen gesamten Lauf hinweg aktiv, Dynamic Variables reichen Werte zwischen Aufrufen weiter, Dependency Chains leiten die Ausführungsreihenfolge daraus ab, was jeder Testfall benötigt und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat. Der letzte Punkt ist für REST wichtiger, als viele erwarten, denn Idempotenzprüfungen bedeuten, dieselbe destruktive Operation absichtlich zweimal aufzurufen.
Das Ergebnis: Ihre eigenen Konventionen werden bei jeder Änderung geprüft, statt nur dokumentiert und erhofft zu werden. Genau das verhindert, dass ein einzelner Endpunkt klammheimlich 200 zurückgibt, wo alle anderen 201 liefern.
Spielt REST-Reinheit beim Testen eine Rolle?
Nur dort, wo Clients sich darauf verlassen. Testen Sie die Konventionen, zu denen sich Ihr Service bekennt, nicht die, die ein Lehrbuch vorschreibt.
Wie testen wir HATEOAS?
Wenn Sie Links zurückgeben, prüfen Sie, dass sie auflösbar sind und dorthin zeigen, wohin sie zu zeigen vorgeben. Wenn nicht, lassen Sie es; nur sehr wenige Services setzen es wirklich um.
Und was ist mit GraphQL?
Völlig andere Konventionen. Statuscodes tragen deutlich weniger Bedeutung, und Fehler kommen konstruktionsbedingt im Body an – die obigen Prüfungen lassen sich daher größtenteils nicht übertragen.
Sollten wir Response-Header prüfen?
Den Content-Type immer. Caching- und Rate-Limit-Header dann, wenn Clients darauf reagieren – was Sie wissen sollten, bevor Sie darauf prüfen.
Lohnt es sich, Versionierung zu testen?
Ja, wenn Sie mehr als eine Version unterstützen. Prüfen Sie, dass sich eine alte Version weiterhin so verhält wie bisher – denn genau das verspricht eine Versionsnummer.
Testen Sie die Versprechen, die Ihre API gibt.
REST-API-Testing sollte die Konventionen überprüfen, zu denen sich Ihr Service bekennt: Status-Semantik, Idempotenz, Gesamtzahlen bei der Paginierung und die Frage, ob unbekannte Filter abgelehnt werden. Und unter all dem: Prüfen Sie den Body statt des Status.