Was JSONPlaceholder Ihnen bietet
Vorhersehbare Ressourcen. Posts, Kommentare, Benutzer, Todos und Alben – mit stabilen Identifiern und konsistenten Strukturen.
Alle HTTP-Verben. GET, POST, PUT, PATCH und DELETE liefern durchweg sinnvolle Antworten.
Verschachtelte Beziehungen. Kommentare gehören zu Posts, Posts gehören zu Benutzern. Genug Struktur zum Üben.
Die unbeabsichtigte Lektion
Schreibzugriffe auf JSONPlaceholder sind simuliert. Sie senden ein POST, erhalten ein 201 mit einem Identifier – und gespeichert wurde nichts. Rufen Sie den Datensatz wieder ab, ist er nicht da.
Die meisten halten das für eine Einschränkung. Tatsächlich ist es das Nützlichste am ganzen Dienst, denn es trennt zwei Dinge, die Einsteiger regelmäßig vermischen: die Anfrage war erfolgreich und die Änderung hat stattgefunden. Eine Suite, die auf Statuscodes prüft, besteht hier jeden Schreibtest – zuverlässig und für immer.
Wenn Ihre Assertion die simulierten Schreibzugriffe von JSONPlaceholder übersteht, ist sie eine schwache Assertion. Schreiben Sie sie so um, dass sie prüft, ob das Objekt danach tatsächlich existiert – und nehmen Sie diese Gewohnheit mit zu Ihrer echten API, wo dieselbe Schwäche unsichtbar bleibt.
Was Sie hier üben sollten – in dieser Reihenfolge
Strukturen und Felder
Prüfen Sie die Struktur des Response-Body statt des Status.
Prüfen Sie Typen, nicht nur das Vorhandensein.
Beziehungen
Rufen Sie einen Post ab, dann dessen Kommentare, und prüfen Sie, ob diese tatsächlich darauf verweisen.
Die meisten echten Fehler stecken zwischen zwei Aufrufen.
Fehlerpfade
Fragen Sie einen Identifier ab, den es nicht gibt, und prüfen Sie, ob die Antwort korrekt aufgebaut ist.
Der Test, den alle auslassen – und der, der etwas findet.
Was es nicht vermitteln kann
Alles Zustandsbehaftete – und damit alles, was API-Tests in der Praxis schwierig macht. Sessions und ihr Ablauf, Werte, die aus einer Antwort übernommen und in der nächsten verwendet werden, Aufrufe, die in einer bestimmten Reihenfolge erfolgen müssen, und das Aufräumen nach einem Lauf. Nichts davon gibt es bei JSONPlaceholder, weil nichts persistiert wird.
Als erste Stunde ist der Dienst also hervorragend, als zweite Woche irreführend. Wechseln Sie zu einer API mit echtem Zustand, sobald Ihnen die Grundlagen leichtfallen – und rechnen Sie mit einem deutlichen Sprung im Schwierigkeitsgrad.
Eine erste Stunde, die sich übertragen lässt
Damit das Geübte auch bei Ihrer eigenen API etwas wert ist, arbeiten Sie diese vier Schritte der Reihe nach ab, statt planlos herumzuprobieren.
Rufen Sie einen Post ab und prüfen Sie drei konkrete Felder samt ihrer Typen – nicht nur, ob der Aufruf erfolgreich war. Rufen Sie einen Post ab, den es nicht gibt, und prüfen Sie den Status und den Aufbau der Antwort. Rufen Sie einen Post ab, dann dessen Kommentare, und prüfen Sie, dass jeder Kommentar auf genau den angefragten Post verweist. Legen Sie anschließend einen Post an, rufen Sie ihn wieder ab – und sehen Sie zu, wie die Assertion fehlschlägt.
Der letzte Schritt ist der eigentliche Sinn der ganzen Übung. Der Schreibzugriff meldete Erfolg, der Identifier kam zurück – und persistiert wurde nichts. Jede Gewohnheit, die es wert ist, auf eine echte API übertragen zu werden, steckt darin, zu erkennen, warum Ihr Test trotzdem bestanden hat, und ihn so umzuschreiben, dass er es nicht mehr tut.
Der Wechsel zu einem echten Dienst
Genau diese vier Punkte deckt eine eigens dafür gebaute Schicht als Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup ab. Wie das im Einzelnen funktioniert, steht in der Dokumentation zum API-Testing.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Das Dashboard bietet dasselbe für alle, die keine lokale Installation möchten; der vollständige Befehlsumfang findet sich im CLI-Repository.
Was sich ändert, wenn Sie es auf eine echte API richten
Alles, was JSONPlaceholder nicht vermitteln kann, übernimmt TestSprite. Auto-Authentication für Sessions, die mitten im Lauf ablaufen. Dynamic Variables für den Identifier, den ein Create-Aufruf zurückgibt. Dependency Chains für Aufrufe, die erst nach einem anderen stattfinden können. Auto-Cleanup für die Datensätze, die jeder Lauf hinterlässt.
Der erste Schritt ist derselbe wie in der Übung oben: Richten Sie ein Projekt auf Ihre Basis-URL, lassen Sie API Discovery erfassen, was vorhanden ist, und lesen Sie den generierten Plan, bevor Sie irgendetwas ausführen. Der Unterschied: Der Plan deckt nun Autorisierung und Grenzfälle gegen einen Dienst ab, bei dem Schreibzugriffe tatsächlich persistiert werden.
Was Sie gewinnen, ist genau das, worauf die Übung hinauslief: Assertions, die dem Kontakt mit echtem Zustand standhalten – und die bei jeder Änderung laufen statt dann, wenn Sie daran denken.
Warum werden meine POST-Anfragen nicht gespeichert?
Das ist so gewollt. JSONPlaceholder simuliert Schreibzugriffe. Nehmen Sie es als Lektion darin, auf Ergebnisse zu prüfen statt auf Antworten.
Eignet es sich für CI?
Für eine Tutorial-Suite gelegentlich. Für alles, was bei jedem Commit läuft, nehmen Sie besser einen lokalen Mock. Es ist ein kostenloser, gemeinsam genutzter Dienst.
Wozu sollte ich als Nächstes wechseln?
Zu etwas mit Authentifizierung und echter Persistenz. Der Sprung im Schwierigkeitsgrad ist genau der Punkt – dort beginnt das übertragbare Können.
Kann ich einen Testgenerator darauf ansetzen?
Ja, und es ist ein sicherer Ort, um zu sehen, wie generierte Abdeckung aussieht, denn es gibt nichts, was sich verunreinigen ließe.
Gibt es Alternativen?
HTTPBin für gezielt herbeigeführte Fehler und Statuscodes, PokeAPI für Pagination in größerem Umfang, eine öffentliche GitHub-API für authentifiziertes Verhalten.
Die simulierten Schreibzugriffe sind hier die beste Lektion.
JSONPlaceholder vermittelt gefahrlos den Aufbau von Anfragen, Beziehungen und Fehlerpfade. Seine simulierten Schreibzugriffe legen den Unterschied zwischen einer erfolgreichen Anfrage und einer tatsächlichen Änderung offen – und genau diese Gewohnheit lohnt es mitzunehmen. Wechseln Sie zu einer zustandsbehafteten API, sobald die Grundlagen sitzen.