Du bekommst einen REST-Endpunkt ohne Dokumentation. Was testest du?

Fang beim Vertrag an: Statuscodes, Response-Schema, Content-Types und Pflicht- gegen optionale Felder. Dann validier jede Eingabe (fehlend, falscher Typ, außerhalb des Bereichs, zu groß), teste Authentifizierung und Autorisierung inklusive Zugriff auf die Ressource eines anderen Nutzers, prüf die Konsistenz der Fehlerantworten, Idempotenz bei doppelten Submits, Pagination und Sortierung, Rate Limiting und das Verhalten, wenn eine Abhängigkeit ausfällt oder in ein Timeout läuft.

Zuerst kartiere ich den Vertrag, denn ohne Doku muss ich die Form kennen, bevor ich sie beurteilen kann. Aufruf auf dem glücklichen Pfad, dann schaue ich auf Statuscode, Header, Response Body und darauf, ob Felder konsistent benannt und typisiert sind. Dann greife ich die Eingaben einzeln an: jedes Pflichtfeld weglassen, einen String schicken, wo eine Zahl hingehört, einen negativen Wert schicken, einen Wert jenseits jeder vernünftigen Länge schicken, zusätzliche Felder schicken, nach denen nicht gefragt wurde, und schauen, ob sie abgelehnt oder still ignoriert werden. Dann der Teil, der mir am wichtigsten ist: Autorisierung als etwas anderes als Authentifizierung. Eingeloggt zu sein ist keine Berechtigung. Ich nehme also ein gültiges Token eines Nutzers und fordere die Ressource eines anderen per ID an, denn diese Bugklasse ist häufig und wirklich schwerwiegend. Danach: legt ein wiederholtes POST zwei Datensätze an, wie verhält sich Pagination bei Seite null und hinter dem Ende, sind Fehlerbodies formgleich, gibt es Rate Limiting, und was passiert, wenn ein Downstream-Service langsam ist. Ich hänge einen Proxy davor und manipuliere Antworten, um zu sehen, ob es degradiert oder eine 500 wirft.