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.
