[API как продукт] Testumgebung / Sudo Null IT News

Das ist Kapitel 31 mein kostenloses API-Buch.

Wenn über Ihre API Operationen durchgeführt werden, die Folgen für Benutzer oder Partner haben (insbesondere Geld kosten), benötigen Sie eine Testversion dieser API. In der Test-API finden reale Aktionen entweder gar nicht statt (z. B. wird ein Auftrag erstellt, aber niemand führt ihn aus) oder es wird auf billige Weise simuliert (z. B. anstatt eine SMS an die Nummer eines Benutzers zu senden, eine E-Mail wird an das Postfach des Entwicklers gesendet).

In vielen Fällen reicht dies jedoch nicht aus – wie beispielsweise in unserem fiktiven API-Beispiel für Kaffeemaschinen. Wenn eine Bestellung einfach erstellt, aber nicht ausgeführt wird, können Partner nicht testen, wie die Funktionalität zum Erteilen einer Bestellung oder zum Beispiel zum Beantragen einer Rückerstattung in ihrer Anwendung funktioniert. Um einen vollständigen Testzyklus durchführen zu können, ist es notwendig, dass dieser virtuelle Auftrag auf andere Status übertragen werden kann – so wie es in der Realität passieren wird.

Die Lösung dieses Problems “in der Stirn” ist die Bereitstellung eines vollständigen Satzes von Test-APIs und Verwaltungsschnittstellen. Diese. Der Entwickler muss parallel die zweite Anwendung starten – diejenige, die Sie Coffeeshops zur Verfügung stellen, damit sie die Bestellung annehmen und ausführen können (und wenn eine Kurierzustellung vorgesehen ist, dann auch die dritte – die Kurieranwendung) – und ausführen Aktionen in dieser Anwendung, die ein Mitarbeiter normalerweise Kaffeehäuser durchführt. Offensichtlich ist dies aus vielen Gründen bei weitem nicht die bequemste Option:

  • der Entwickler einer Benutzeranwendung muss zusätzlich die Bedienung von Anwendungen für Cafés und Kuriere verstehen, die im Allgemeinen nichts mit seinen Aufgaben zu tun haben;

  • Es müssen einige Bindungsalgorithmen entwickelt und implementiert werden: Eine Bestellung, die über eine Testanwendung aufgegeben wird, muss zur Ausführung an den erforderlichen virtuellen Kurier gesendet werden; Dies bedeutet eigentlich, dass Sie in der Test-API für jeden Partner separat eine virtuelle “Sandbox” (sprich: einen vollständigen Satz von Diensten) erstellen müssen.

  • Der vollständige glückliche Pfad einer Bestellung dauert Minuten, manchmal mehrere zehn Minuten, und erfordert viele Aktionen, die in mehreren Schnittstellen ausgeführt werden müssen.

Es gibt zwei Möglichkeiten, diese Art von Problem zu vermeiden.

1. API der Testumgebung

Die erste Option besteht darin, der Testumgebung selbst eine Meta-API bereitzustellen. Anstatt die Coffee-Shop-Anwendung in einem separaten Emulator auszuführen, werden dem Entwickler Hilfsmethoden (z. B. SimulierenOrderPreparation) oder eine spezielle visuelle Schnittstelle zur Verfügung gestellt, um das Bestellerfüllungsszenario mit minimalem Aufwand zu verwalten.

Idealerweise sollten Sie Hilfsmethoden für Testumgebungen für alle Aktionen haben, die von Menschen in einer realen Produktionsumgebung ausgeführt werden. Es ist sinnvoll, solche Meta-APIs sofort mit vorgefertigten Skripten oder Sammlungen von Anfragen auszuliefern, die die korrekte Reihenfolge der Aufrufe verschiedener APIs demonstrieren, um Standardszenarien zu simulieren.

Der Nachteil dieses Ansatzes besteht darin, dass der Entwickler der Client-Anwendung immer noch verstehen muss, wie die „Unterseite“ des Systems funktioniert, wenn auch in vereinfachter Form.

2. Simulator vordefinierter Szenarien

Eine Alternative zur Testumgebungs-API ist die Simulation von Arbeitsszenarien, wenn die Testumgebung die Kontrolle über den „Unterwasser“-Teil des Systems übernimmt. In unserem Kaffee-Beispiel sieht das so aus: Nach der Bestellung simuliert das System automatisch alle Schritte der Zubereitung und anschließend den Eingang der Bestellung beim Endverbraucher.

Der Vorteil dieses Ansatzes ist eine klare Demonstration, wie das System nach der Vorstellung des API-Anbieters funktioniert, welche Ereignisse in welcher Reihenfolge generiert werden und welche Phasen die Bestellung durchläuft. Darüber hinaus wird die Möglichkeit von Fehlern in Testskripten reduziert, da der API-Anbieter sicherstellt, dass die Aktionen in der richtigen Reihenfolge und mit den richtigen Parametern ausgeführt werden.

Der Hauptnachteil ist die Notwendigkeit, ein separates Skript für alle möglichen unglücklichen Pfade zu entwickeln, d.h. für jeden möglichen Fehler, und es ist auch notwendig, dem Entwickler die Möglichkeit zu geben, festzulegen, welche der Szenarien er reproduzieren möchte. (Zum Beispiel wie folgt: Wenn ein Auftrag mit einem Kommentar einer bestimmten Art erstellt wird, wird ein Fehler in seiner Ausführung emuliert, und der Entwickler kann die richtige Reaktion auf diese Art von Fehlern debuggen.)

Testautomatisierung

Ihr ultimatives Ziel bei der Entwicklung einer Test-API, egal für welche Option Sie sich entscheiden, ist es, Partnern zu ermöglichen, das Testen ihrer Produkte zu automatisieren. Mit dieser Sichtweise sollte die Entwicklung einer Testumgebung erfolgen; Wenn es beispielsweise zum Bezahlen einer Bestellung erforderlich ist, den Benutzer auf die 3-D Secure-Seite zu übertragen, sollte die API der Testumgebung die Möglichkeit bieten, den Durchgang (oder das Scheitern) des Benutzers dieses Typs programmgesteuert zu simulieren der Verifizierung. Darüber hinaus ist es in beiden Fällen möglich (und eher sogar wünschenswert), Skripte in einem beschleunigten Zeitrahmen auszuführen, wodurch automatisches Testen viel schneller durchgeführt werden kann als manuelles Testen.

Natürlich werden nicht alle Partner diese Möglichkeit nutzen können (was unter anderem bedeutet, dass neben der Software auch der „manuelle“ Weg zum Testen von Benutzerszenarien unterstützt werden sollte), einfach weil nicht alle Unternehmen dies können leisten, einen Testautomaten zu mieten. Dennoch ist gerade die Fähigkeit, solche Autotests zu schreiben, in den Augen technisch fortgeschrittener Partner ein enormer Wettbewerbsvorteil Ihrer API.

Similar Posts

Leave a Reply

Your email address will not be published.