Bei einem API-Test wird die Überprüfung der Schnittstellen durchgeführt, die Softwaresysteme miteinander verbinden. Dabei werden nicht nur REST-Protokolle abgedeckt, sondern auch GraphQL, Webhooks und SOAP. Jedes Protokoll hat seine eigenen Regeln und Vor- und Nachteile. Gut konzipierte APIs reduzieren zudem die Anzahl der Aufrufe, die KI-Agenten tätigen müssen, was den Token-Verbrauch und die Kosten direkt senkt. Damit ist die API-Architektur nicht nur eine funktionale, sondern auch eine Frage der Qualität.
Das Wichtigste in Kürze
- Für den Einsatz durch Agenten optimierte APIs benötigen weniger Anforderungen, um dieselben Daten abzurufen, was den Token-Verbrauch direkt reduziert und die Betriebskosten senkt.
- REST ist eine Reihe von Empfehlungen, kein strenges Protokoll, sodass Teams von den Konventionen abweichen können und dies auch tun, ohne gegen einen formalen Standard zu verstoßen.
- Bei MCP sendet der MCP-Server zu Beginn einer Sitzung eine Beschreibung seiner verfügbaren Tools und Ressourcen an das LLM – so lernt das Modell, welche Aktionen es aufrufen kann.
- Tests auf API-Ebene bieten mehr Stabilität und eine schnellere Ausführung als End-to-End-Browsertests, und die richtige Teststrategie legt fest, auf welcher Ebene jedes Szenario am besten abgedeckt wird, anstatt standardmäßig auf Frontend-Automatisierung zurückzugreifen.
- Wenn man den Testentwurf für API-Tests anhand von Dokumentationen wie einer Swagger-Spezifikation beginnt, noch bevor das Frontend existiert, entfallen Wartezeiten am Ende des Entwicklungszyklus und es wird Leerlauf vermieden.
APIs sind die Schnittstelle, die die meisten Tester immer noch ignorieren
Tester lieben das Frontend. Das Klicken, den Browser, den sichtbaren Ablauf. Durch diesen Fokus bleibt die darunterliegende Ebene ungetestet, obwohl das Frontend oft der unstabilste Ort ist, um einen Fehlerzustand zu entdecken.
Das Backend liefert dir vorhersehbares, schnelleres Feedback. Eine Anfrage wird gesendet, eine Antwort kommt zurück, und das Ergebnis ist wiederholbar. Frontend-Tests sind oft unzuverlässig. Wenn etwas zuverlässig und schnell laufen muss, ist die API-Ebene der entscheidende Faktor.
Sebastian Malyska bezeichnet sich selbst als Back-Ender aus Überzeugung. Wenn er einen Front-End-Test erstellen muss, verlagert er die Logik, wo immer möglich, hinunter in Richtung API. Nicht nur aus Vorliebe, sondern weil das Back-End eine vorhersehbarere Ausgabe liefert.
Der Rat ist einfach: Lass dich nicht vom Hype darüber mitreißen, welches Frontend-Framework gewinnt. Verstehe, was hinter den Kulissen passiert: Welche Protokolle transportieren die Daten, und wie kommunizieren die Systeme miteinander?
Hinter dem Begriff „API“ verbergen sich fünf verschiedene Dinge
„Wir testen die API“ ist zu vage, um nützlich zu sein. Hinter diesem Begriff verbergen sich mehrere Protokollarten, die sich unterschiedlich verhalten. Der Bericht von Postman über Zehntausende von Unternehmen erfasst, welche davon tatsächlich genutzt werden.
REST steht an der Spitze und bleibt dort Jahr für Jahr. Webhooks sind auf dem Vormarsch. GraphQL belegte in den Daten von 2024 den zweiten Platz und ist seitdem zurückgefallen. Die oberste Gruppe bleibt im Großen und Ganzen stabil: REST, Webhooks, GraphQL und ein paar weitere.
REST ist eine Empfehlung, kein strenges Protokoll. Wenn jemand beschließt, ein Objekt mit einer GET-Anfrage zu entfernen, ist das erlaubt, auch wenn es gegen die Konvention verstößt. Es gab wahrscheinlich einen Grund dafür. Man bringt denjenigen deswegen nicht um.
SOAP ist der gegenteilige Fall. Es ist ein standardisiertes Protokoll, das dort zum Einsatz kommt, wo es auf Genauigkeit ankommt: Geld, Zeit, Integration von Drittanbietern. Der Betrag, der Zeitpunkt und das Format werden alle vorab validiert, weil es die hohen Anforderungen erfordern.
GraphQL wurde entwickelt, um übermäßiges Abrufen zu verhindern. Anstatt Objekt A, Objekt B und Objekt C abzurufen und sie auf der Client-Seite abzugleichen, sendest du eine einzige Anfrage, die genau die Daten benennt, die du willst. Der Server gibt genau das zurück – und nichts weiter.
Wenn du diese Unterschiede kennst, kannst du entscheiden, wo ein Test hingehört. Ohne dieses Wissen ist „API-Test“ reine Spekulation.
MCP ist der Proxy, der KI-Agenten echte Daten liefert
MCP ist die Ebene, die Sprachmodelle mit echten Systemen verbindet, damit sie aufhören zu „halluzinieren“. Die gängige Analogie „MCP ist wie USB für Computer“ erklärt gar nichts. Ein treffenderes Bild: MCP ist die Verbindung zu einem externen Gerät, das das Modell sonst niemals erreichen würde.
Ein Sprachmodell ist eine clevere Box, aber es bleibt in dieser Box. Um in der realen Welt zu agieren, muss es mit echten Systemen interagieren. Diese Systeme sprechen immer noch die alten Protokolle. Also muss etwas dazwischen sitzen, eine Art Proxy, der auf der einen Seite mit dem LLM und auf der anderen Seite mit den klassischen Protokollen kommuniziert.
Die Kommunikation läuft über Protokolle, die Tester bereits kennen. Standardmäßig wird JSON-RPC verwendet, das über verschiedene darunterliegende Transportschichten übertragen wird.
Die „automatische Erkennung“ eines Agenten ist keine Zauberei. Es gibt einen festgelegten Austausch. Wenn das Modell zum ersten Mal mit einem MCP-Server kommuniziert, sendet der Server Informationen über sich selbst: welche Ressourcen er hat, welche Tools er anbietet. Das Modell merkt sich eher eine kurze Zusammenfassung als alles auf einmal. Es kann dann Folgeanfragen stellen, zum Beispiel, welchen Datentyp ein bestimmtes Tool erwartet.
Diesen Handshake zu verstehen, ist die Aufgabe der Entwickler. Ein Tester, der nicht erklären kann, wie ein System funktioniert, sollte nicht absegnen, dass es funktioniert.
Gutes API-Design spart Tokens und Geld
Eine für Agenten optimierte API kostet weniger Tokens als eine, die nur für Menschen konzipiert ist. Dieser Unterschied schlägt sich direkt im Budget nieder.
Die meisten Teams entwerfen APIs immer noch so, wie sie es schon immer getan haben: eine Geschäftsidee, aufgeteilt in Domänen und Unterdomänen, dann in Code umgesetzt. Das Ergebnis ist für einen Menschen logisch nachvollziehbar. Eine Bestellung innerhalb einer Bestellung, dann eine Rechnung – ein Pfad, dem man in einer Benutzeroberfläche folgen kann. Für einen Agenten ist diese Struktur nicht effizient.
Nur sehr wenige Unternehmen entwerfen ihre APIs mit Blick auf die Nutzung durch Agenten, obwohl ihre Entwickler MCP kennen und ihre Tester bereits agentenbasierte Tools verwenden. Die Optimierungsmöglichkeit liegt auf der architektonischen Ebene und beginnt mit einer Frage, die Tester bereits zu stellen wissen: Wer sind die Stakeholder, und was bedeutet gute Qualität für sie?
Niemand fragt die KI, ob sie lieber fünf Anfragen oder eine einzige senden würde. Aber die Token-Anzahl am Monatsende gibt darauf ohnehin eine Antwort. Eine gut konzipierte API bedeutet weniger Roundtrips, weniger zu übertragenden Kontext und eine geringere Rechnung. Größere Modelle bedeuten größere Kontextfenster, was die Versuchung weckt, einfach mehr Daten hineinzupacken. Ein besseres Design macht genau das Gegenteil.
Performanztests werden als altmodisch abgetan. Richtig durchgeführt, werfen sie genau die Fragen auf, die es jetzt zu stellen lohnt: Wie schaffen wir das mit weniger Ressourcen? Leistung zu verbessern bedeutet nicht, AWS eine Goldkarte zu geben und nach mehr Maschinen zu fragen. Das ist der harte Weg, der technische Weg, und er führt zu Fehlerzuständen mit echtem Fehlerschweregrad und echten Auswirkungen.
Eine Teststrategie braucht sowohl API-Tests als auch Ende-zu-Ende-Tests
Die stärkste Teststrategie deckt beide Ebenen ab, und zwar Funktion für Funktion. Weder eine vollständige Ende-zu-Ende-Überdeckung noch reine API-Tests sind für sich genommen die Lösung.
End-to-End-Automatisierung wird oft als das Nonplusultra angesehen. Der Drang, „alles über die Benutzeroberfläche zu automatisieren“, ist groß, besonders bei Entwicklern, die das Frontend lieben. Aber die Zahlen sprechen für sich. Zweitausend API-Tests können in derselben Zeit ihre Arbeit erledigen wie dreihundert Playwright-Szenarien. Das ist kein Wettstreit darum, wer gewinnt, denn manche Dinge müssen an der Benutzeroberfläche geprüft werden, andere im Backend. Es ist ein Grund, nachzudenken, bevor man sich standardmäßig für Ende-zu-Ende-Tests entscheidet.
Die Testpyramide ist immer irgendwo im Hintergrund präsent. Ob die genauen Anteile einer Pyramide entsprechen sollten, ist eine andere Frage. Nimm dir die Funktion genau vor, schau sie dir ehrlich an und entscheide, welche Ebene für die jeweilige Prüfung am besten geeignet ist. Und dränge die Entwickler dazu, ihre Unit-Tests durchzuführen.
Selbstheilende Frontend-Szenarien werden immer besser und könnten UI-Tests gegenüber sich ändernden Websites stabiler machen. Trotzdem kostet diese Selbstheilung zusätzliche Rechenleistung und Zeit. Der Kompromiss bleibt bestehen.
Manche Verhaltensweisen betreffen ausschließlich das Frontend und müssen dort getestet werden. Andere betreffen ausschließlich das Backend. Um zu entscheiden, wo die jeweilige Prüfung hingehört, muss man beide Schichten verstehen – und diese Entscheidung trifft man am besten gemeinsam mit den Entwicklern.
Wenn du dich nur mit dem Frontend auskennst, fang hier an
Du wirst keine Probleme bekommen, wenn du dich in Richtung APIs bewegst. Viele Frontend-Entwickler arbeiten bereits so, ohne es als neue Fähigkeit zu bezeichnen.
Das Muster ist üblich: Ende-zu-Ende-Tests laufen zu langsam, daher werden Setup und Teardown in die API verlagert. Aktionen vor dem Test erfolgen über eine andere API. Dann öffnet sich der Browser, die Klicks werden ausgeführt, der Browser schließt sich und die Bereinigung läuft erneut über die API. Fortgeschrittene Entwickler erledigen die gesamte Vorbereitung selten noch über die Benutzeroberfläche.
Deine Tools weisen dir bereits den Weg. Playwright, ein Frontend-Tool, verfügt über einen integrierten API-Client. Es gab eine Zeit, in der man einen separaten Client installieren und selbst zusammenbasteln musste. Die Framework-Autoren betrachten den API-Zugriff mittlerweile als selbstverständlich – das zeigt dir, wohin sich die Branche entwickelt.
Konkrete nächste Schritte, sobald du REST hinter dir hast:
- Lerne, dass REST nicht das einzige Protokoll ist. GraphQL, Webhooks und andere lösen jeweils unterschiedliche Probleme.
- Nutze Mocking, um Randfälle im Frontend zu testen, ohne auf ein live laufendes Backend angewiesen zu sein.
- Lies die API-Dokumentation frühzeitig. Eine Workshop-Übung beginnt mit nichts als einer Swagger-Spezifikation: Das ist dein Server, das ist die einzige Dokumentation – erarbeite den Happy Flow.
Tester haben nicht das Privileg, auf ein fertiges, gut aussehendes Frontend zu warten. Während der Entwicklung musst du die Dokumentation lesen, verstehen, was das Backend macht, und damit anfangen zu testen. Wenn das Frontend fertig ist, führst du das aus, was du bereits erstellt hast. Warten ist Verschwendung, und Verschwendung ist nicht gut.
Häufig gestellte Fragen
Warum liefern Tests auf API-Ebene mehr zuverlässige Rückmeldungen als Tests über den Browser?
Eine Anfrage wird gesendet, eine Antwort kommt zurück, und das Ergebnis ist wiederholbar. Frontend-Tests sind oft unzuverlässig, was die sichtbare Ebene zum instabilsten Ort macht, um einen Fehler zu entdecken. Erfahrene Entwickler verlagern die Logik in Richtung API, selbst wenn sie einen Frontend-Test erstellen, da das Backend eine besser vorhersehbare Ausgabe liefert.
Sind REST und SOAP als Standards gleichermaßen verbindlich?
Nein. REST ist eine Reihe von Empfehlungen, kein strenges Protokoll. Ein Team, das also ein Objekt mit einer GET-Anfrage entfernt, verstößt zwar gegen die Konvention, aber nicht gegen einen formalen Standard. Dafür gab es wahrscheinlich einen Grund. SOAP ist der gegenteilige Fall: ein standardisiertes Protokoll, das dort zum Einsatz kommt, wo Genauigkeit zählt – etwa bei Geld, Zeit und der Integration von Drittanbietern –, wobei Betrag, Zeit und Format vorab validiert werden.
Was macht GraphQL anders, als mehrere Objekte nacheinander abzurufen?
Es verhindert das übermäßige Abrufen von Daten. Anstatt Objekt A, Objekt B und Objekt C abzurufen und sie auf der Client-Seite abzugleichen, benennt eine einzige Anfrage genau die gewünschten Daten, und der Server gibt genau diese zurück – und nichts weiter. Wenn du solche Unterschiede zwischen den Protokollen kennst, kannst du entscheiden, wo ein Test hingehört; ohne dieses Wissen ist das API-Testen reine Spekulation.
Wie lernt ein Sprachmodell, welche Aktionen ein MCP-Server zulässt?
Durch einen definierten Austausch, nicht durch magische Erkennung. Wenn das Modell zum ersten Mal mit einem MCP-Server kommuniziert, sendet der Server Informationen über sich selbst: welche Ressourcen er hat und welche Tools er anbietet. Das Modell speichert eher eine kurze Zusammenfassung als alles auf einmal und kann Folgeanfragen senden, zum Beispiel zum Datentyp, den ein Tool erwartet. Standardmäßig wird JSON-RPC verwendet.
Hat das Design einer API Auswirkungen darauf, wie viel der Betrieb von KI-Agenten kostet?
Ja. Eine für den Einsatz von Agenten optimierte API benötigt weniger Anfragen, um dieselben Daten abzurufen – das bedeutet weniger Hin- und Rückläufe, weniger zu übertragenden Kontext und geringere Kosten. Die meisten Teams unterteilen eine Geschäftsidee immer noch in Domänen und Unterdomänen und setzen diese Struktur im Code um. Das ist für einen Menschen logisch nachvollziehbar, für einen Agenten jedoch ineffizient.
Sollte die Testautomatisierung standardmäßig auf die Benutzungsschnittstelle ausgerichtet sein?
Nein. Zweitausend API-Tests können ihre Arbeit in derselben Zeit erledigen wie dreihundert Playwright-Szenarien – ein Grund, es sich gut zu überlegen, bevor man sich für Ende-zu-Ende-Tests entscheidet. Manche Verhaltensweisen gibt es nur im Frontend, andere nur im Backend – daher wird die Ebene Feature für Feature festgelegt, idealerweise gemeinsam mit den Entwicklern.
Wie kann man mit dem Testen beginnen, bevor das Frontend fertig ist?
Indem man anhand der API-Dokumentation arbeitet. Eine Workshop-Übung beginnt mit nichts anderem als einer Swagger-Spezifikation: Das ist dein Server, das ist die einzige Dokumentation – erarbeite den Happy Flow. Mocking deckt Randfälle ab, ohne dass ein live Backend vorhanden ist. Wenn das Frontend fertig ist, führst du das aus, was du bereits erstellt hast, anstatt am Ende des Zyklus zu warten.
