Die vier Ebenen funktionaler API-Tests
1. Status
Kam eine 200 zurück.
Findet Ausfälle. Läuft klaglos durch, wenn ein leeres Ergebnis zurückkommt, obwohl dort ein Datensatz stehen müsste.
2. Struktur
Sind die erwarteten Felder mit den erwarteten Typen vorhanden.
Findet Schema-Drift. Sagt nichts darüber aus, ob die Werte stimmen.
3. Wert
Ist der Gesamtbetrag wirklich die Summe, ist der Status derjenige, den diese Aktion erzeugen sollte.
Hier werden erstmals echte Defekte gefunden.
Die vierte ist die Beziehung: Zeigt der Abruf des Kunden die Bestellung an, nachdem sie angelegt wurde. Die interessantesten Fehler liegen zwischen zwei Aufrufen und nicht innerhalb eines einzelnen, und nur Ebene vier schaut dorthin.
Warum Suiten bei Ebene zwei stehen bleiben
Weil die Ebenen drei und vier wissen müssen, was korrekt bedeutet – und das heißt, jemand muss es entscheiden. Status und Struktur lassen sich mechanisch aus einer Spezifikation ableiten. Wert und Beziehung verlangen ein Urteil über das Produkt.
Das ist tatsächlich schwieriger, und genau darin liegt der gesamte Nutzen. Eine Suite, die nie eine Produktregel ausdrückt, prüft auf aufwendige Weise, ob der Dienst erreichbar ist.
Der Negativfall, den alle auslassen
Fragen Sie für jeden Endpunkt, was abgelehnt werden sollte, und prüfen Sie dann per Assertion, dass es das auch wird. Werte außerhalb des gültigen Bereichs, fehlende Pflichtfelder, eine Kennung, die jemand anderem gehört. Dienste, die eine 200 mit einem Fehlerobjekt im Body zurückgeben, sind häufig genug, dass eine Suite, die dieses Muster nicht kennt, auf ewig grün meldet.
Was eine Suite als Unterbau braucht
Vier Dinge entscheiden, ob eine API-Suite ihr erstes Jahr übersteht: Sessions, die ablaufen, Werte, die erst zur Laufzeit existieren, Aufrufe, die voneinander abhängen, und Datensätze, die niemand aufräumt. TestSprite deckt das mit Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup ab, beschrieben in der Dokumentation zum API-Testing.
Erst wenn diese Dinge sitzen, können Sie Ihre Aufmerksamkeit auf die Ebenen drei und vier richten statt auf Infrastruktur.
Über die oberflächliche Abdeckung hinauskommen
Generierte Pläne gehen von einer Spezifikation oder einem Discovery-Durchlauf aus und umfassen die Kategorien Funktion, Schema, Autorisierung, Fehlerbehandlung und Grenzwerte. Die Negativfälle sind damit von vornherein vorhanden, statt davon abzuhängen, dass sich am Ende eines Sprints jemand an sie erinnert.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Dasselbe Setup steht im TestSprite-Dashboard zur Verfügung, wenn Sie lokal nichts installieren möchten. Der übrige Funktionsumfang der CLI findet sich im CLI-Repository.
Auswählen, welche Endpunkte Ebene vier bekommen
Beziehungs-Assertions sind die wertvollsten und zugleich die teuersten, deshalb gehören sie nicht überallhin. Der Filter, der funktioniert, ist die Frage, was eine falsche Antwort kosten würde.
Alles, was Geld bewegt, Berechtigungen ändert oder die Grundlage für die Entscheidung einer anderen Person bildet, bekommt Ebene vier. Eine Bestellung, die existiert, aber keinem Kunden zugeordnet ist; eine Berechtigungsvergabe, die nur auf einer Seite erfolgreich war; ein Bericht, der in sich stimmig ist und den zugrunde liegenden Datensätzen widerspricht. Das sind die Fehler, die teuer sind und leise.
Lesende Reporting-Endpunkte, Health Checks und alles, dessen Ausgabe ohnehin sofort jemand in Augenschein nimmt, brauchen sie nicht. Nur wer hier bewusst auswählt, hält die Suite schnell genug, dass sie auch ausgeführt wird.
Bei jeder Änderung ausführen
Zwei Wege, und die Wahl hängt eigentlich davon ab, wer die Pipeline verantwortet. Die Anbindung der GitHub App über das Dashboard erfordert überhaupt keine Änderung an Ihrem Repository, weil sie auf das Deployment reagiert, das Ihr Build ohnehin erzeugt. Ein Schritt mit GitHub Actions legt die Prüfung ins Repository, wo sie wie der Rest des Builds reviewt wird.
Wie TestSprite Sie über Ebene zwei hinausbringt
Generierte Pläne enthalten die Negativfälle standardmäßig, über die Kategorien Funktion, Schema, Autorisierung, Fehlerbehandlung und Grenzwerte hinweg – genau dort geht den meisten handgeschriebenen Suiten die Puste aus. Sie verfeinern die Pläne in natürlicher Sprache, und über diese Verfeinerung fließt Ihr Produktwissen in die Suite ein.
Die Ebenen Wert und Beziehung sind die, die Ihre Aufmerksamkeit verdienen, und sie sind zugleich die, für die jemand nötig ist, der das Produkt kennt. Auto-Authentication hält Sessions über einen Lauf hinweg am Leben, Dynamic Variables tragen Werte zwischen Aufrufen weiter, Dependency Chains leiten die Ausführungsreihenfolge daraus ab, was jeder Fall benötigt und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat – so fließt Ihre Zeit in die Frage, was korrekt bedeutet, statt in Infrastruktur.
Das Ergebnis ist eine Suite, die Bodies und Beziehungen zwischen Aufrufen per Assertion prüft und bei jeder Änderung läuft – statt einer grünen Pipeline, die belegt, dass der Dienst erreichbar ist.
Sind Assertions auf Statuscodes nutzlos?
Nein, sie sind nur die Untergrenze. Behalten Sie sie bei und ergänzen Sie mindestens eine Assertion auf Wertebene pro Endpunkt, auf den es ankommt.
Wie entscheiden wir, was korrekt bedeutet?
Fragen Sie, was das Produkt verspricht, nicht was der Code tut. Kann das für einen Endpunkt niemand beantworten, ist schon diese Unklarheit es wert, sichtbar gemacht zu werden.
Sollte jeder Endpunkt alle vier Ebenen bekommen?
Nein. Reservieren Sie die Ebenen drei und vier für Endpunkte, bei denen ein falscher Wert Folgen hat. Reporting-Endpunkte und Health Checks brauchen sie nicht.
Was ist mit generierten Assertions?
Für die Ebenen eins und zwei nützlich, die mechanisch sind. Die Ebenen drei und vier profitieren von einem Review, denn dort fließt Produktwissen ein.
Wie viele Negativfälle pro Endpunkt?
Ein oder zwei, auf die es ankommt, schlagen zehn, die jede mögliche fehlerhafte Eingabe durchzählen. Wählen Sie die Ablehnungen, die ein echter Client auslösen würde.
Status und Struktur sind die Untergrenze, nicht die Aufgabe.
Funktionale API-Tests haben vier Ebenen der Assertion, und die meisten Suiten bleiben bei der zweiten stehen. Gefunden werden Defekte durch Assertions auf Wert und Beziehung – und der Negativfall ist der, den alle auslassen.