Testtechniken für Serverless-Anwendungen

Es gibt drei Hauptansätze für die Ausführung von Tests mit Serverless-Anwendungscode: Mocktests, Testen in der Cloud und Emulationstests. Im Allgemeinen finden Sie im Rahmen eines einzelnen Projekts eine Mischung dieser Ansätze. Sie könnten beispielsweise Mocktests verwenden, wenn Sie Ihren Code lokal entwickeln, aber Ihr Code könnte im Rahmen eines nächtlichen CI/CD-Prozesses (Continuous Integration and Continuous Delivery) in der Cloud getestet werden.

Mocktests

Mocktests sind eine Strategie, bei der Sie Ersatzobjekte in Ihrem Code erstellen, die das Verhalten von Cloud-Services simulieren. Beispielsweise können Sie einen Test schreiben, der einen Mock des Amazon-S3-Services verwendet, der bei jedem Aufruf der CreateObject-Methode eine bestimmte Antwort zurückgibt. Wenn der Test ausgeführt wird, gibt der Mock die Antwort zurück, ohne Amazon S3 oder andere Service-Endpunkte aufzurufen.

Diese Ersatzobjekte werden häufig von einem Mock-Framework generiert, um den Implementierungsaufwand für einen bestimmten Test zu reduzieren. Einige Mock-Frameworks sind generisch und andere wurden speziell für AWS-SDKs entwickelt.

Mocks fallen zusammen mit Stummeln in die breitere Kategorie von Fälschungen. Mocks unterscheiden sich von Emulatoren (die weiter unten in diesem Abschnitt besprochen werden) dadurch, dass Mocks in der Regel von einem Entwickler als Teil des Testcodes erstellt oder konfiguriert werden, während Emulatoren eigenständige Anwendungen sind, die APIs (z. B. REST-APIs) auf die gleiche Art und Weise offenlegen wie die Systeme, die sie emulieren.

Die Verwendung von Mocks bietet folgende Vorteile:

• Mocks können Dienste von Drittanbietern simulieren, die sich der Kontrolle Ihrer Anwendung entziehen, wie APIs und Software-as-a-Service (SaaS)-Anbieter, ohne dass ein direkter Zugriff auf diese Dienste erforderlich ist.

• Mocks sind auch für das Testen von Fehlerbedingungen nützlich, insbesondere wenn solche Bedingungen (wie z. B. Serviceausfälle) schwer zu simulieren sind.

• Wie Emulatoren können Mock-Frameworks nach ihrer Konfiguration eine schnelle lokale Entwicklung ermöglichen.

• Mocks können Ersatzverhalten für praktisch jede Art von Objekt bereitstellen, so dass Mocking-Strategien eine breitere Palette von Diensten abdecken können als Emulatoren.

• Sobald neue Features oder Verhaltensweisen verfügbar sind, können Mock-Tests schneller reagieren, indem sie ein generisches Mock-Framework verwenden (oder darauf zurückgreifen), das die neuen Features simulieren kann, sobald das aktualisierte AWS-SDK verfügbar ist.

Mock-Tests haben die folgenden Nachteile:

• Mocks erfordern in der Regel einen nicht unerheblichen Einrichtungs- und Konfigurationsaufwand, insbesondere dann, wenn versucht wird, Rückgabewerte von verschiedenen Services zu ermitteln, um die Antworten korrekt nachzuahmen.

• Da Mocks von den Entwicklern geschrieben oder konfiguriert werden, die die Tests schreiben, ist dies eine zusätzliche Verantwortung für Entwickler.

• Möglicherweise benötigen Sie Zugriff auf die Cloud, um die APIs und Rückgabewerte von Diensten zu verstehen.

• Mocks können auch schwierig zu verwalten sein, da sie immer dann aktualisiert werden müssen, wenn sich die simulierten Cloud-API-Signaturen ändern, Rückgabewertschemas weiterentwickeln oder die getestete Anwendungslogik erweitert wird, um Aufrufe an neue APIs zu tätigen. Diese Änderungen bedeuten zusätzlichen Workload für Entwickler bei der Testentwicklung.

• Mocktests können in Desktop-Umgebungen erfolgreich sein, in der Cloud jedoch fehlschlagen.

• Mock-Frameworks sind ebenso wie Emulatoren beim Testen oder Erkennen von AWS Identity and Access Management (IAM)-Richtlinien oder Kontingentbeschränkungen eingeschränkt.

• Auch wenn Mocks besser simulieren können, was eine Anwendung tut, wenn die Autorisierung fehlschlägt oder eine Quota überschritten wird, können Mock-Tests nicht bestimmen, welches Ergebnis tatsächlich eintreten wird, wenn der Code in der Produktionsumgebung bereitgestellt wird.

Testen in der Cloud

Beim Testen in der Cloud werden Tests mit Code ausgeführt, der in einer Cloud-Umgebung statt in einer Desktop-Umgebung bereitgestellt wird. Der Wert von Tests in der Cloud steigt mit der cloudnativen Anwendungsentwicklung. Beispiele:

• Sie können Tests in der Cloud mit den neuesten APIs und Rückgabewerten ausführen.

• Ihre Tests können sich auf IAM-Richtlinien, Service Quotas, Konfigurationen und alle Services beziehen.

• Ihre Cloud-Testumgebung entspricht am ehesten Ihrer Produktions-Laufzeitumgebung, so dass Tests, die Sie in der Cloud ausführen, wahrscheinlich die konsistentesten Ergebnisse erzielen, während sie durch die Umgebungen laufen.

Zu den Nachteilen von Tests in der Cloud gehören:

• Bereitstellungen in Cloud-Umgebungen benötigen in der Regel mehr Zeit als Bereitstellungen in Desktop-Umgebungen. Tools wie AWS Serverless Application Model(AWS SAM) Accelerate, AWS Cloud Development Kit (AWS CDK) watch mode, und SST tragen dazu bei, die Latenz zu verringern, die mit Iterationen der Cloud-Bereitstellung verbunden ist.

• Beim Testen in der Cloud können im Gegensatz zum lokalen Testen, bei dem Ihre lokale Entwicklungsumgebung genutzt wird, zusätzliche Servicekosten anfallen.

• Tests in der Cloud sind möglicherweise weniger durchführbar, wenn Sie keinen Hochgeschwindigkeits-Internetzugang haben.

• Für Tests in der Cloud sind in der Regel Cloud-Umgebungen erforderlich, die voneinander isoliert sind. Umgebungsgrenzen werden häufig auf Stack-Ebene in gemeinsam genutzten Konten für Entwicklerumgebungen gezogen, manchmal mithilfe von Strategien vom Typ Namespace, wie z. B. der Verwendung von Präfixen zur Identifizierung von Eigentümern. In Vorproduktions- und Produktionsumgebungen werden die Grenzen in der Regel auf Kontoebene gezogen, um Workloads von „Noisy-Neighbor“-Problemen zu isolieren und Sicherheitskontrollen mit geringsten Berechtigungen zum Schutz sensibler Daten zu implementieren. Die Notwendigkeit, isolierte Umgebungen zu erstellen, kann die DevOps-Teams zusätzlich belasten, insbesondere wenn sie in einem Unternehmen tätig sind, das strenge Kontrollen in Bezug auf Konten und Infrastruktur hat.

Emulationstest

Emulationstests werden durch lokal laufende Anwendungen, so genannte Emulatoren, ermöglicht, die den AWS-Services ähneln. Emulatoren verfügen über APIs, die ihren Cloud-Gegenstücken ähneln und ähnliche Rückgabewerte bereitstellen. Sie können auch Zustandsänderungen simulieren, die durch API-Aufrufe initiiert werden. Ein Amazon-S3-Emulator könnte beispielsweise ein Objekt auf der lokalen Festplatte speichern, wenn die PutObject-Methode wird aufgerufen wird. Wenn ein GetObject mit demselben Schlüssel aufgerufen wird, liest der Emulator dasselbe Objekt von der Festplatte und gibt es zurück.

Zu den Vorteilen von Emulationstests gehören folgende:

• Sie bieten Entwicklern, die es gewohnt sind, Code in einer lokalen Umgebung zu entwickeln, eine vertraute Umgebung. Wenn Sie beispielsweise mit der Entwicklung einer n-Tier-Anwendung sind, verfügen Sie möglicherweise über einen Datenbank-Engine und einen Webserver, ähnlich denen, die in der Produktion laufen, auf Ihrem lokalen Rechner, um schnelle, lokale, isolierte Testfunktionen bereitzustellen.

• Sie erfordern keine Änderungen an der Cloud-Infrastruktur (z. B. Cloud-Konten für Entwickler), sodass sie einfach mit vorhandenen Testmustern implementiert werden können. Emulationstests bieten die Vorteile schneller, lokaler Entwicklungsiterationen.

Emulatoren haben jedoch auch mehrere Nachteile:

• Sie sind oft schwer einzurichten und zu replizieren, insbesondere wenn sie als Teil von CI/CD-Pipelines verwendet werden. Dies könnte den Workload und den Wartungsaufwand für IT-Mitarbeiter oder Entwickler, die ihre eigenen Softwareinstallationen verwalten, erhöhen.

• Emulierte Feature und APIs hinken in der Regel den Änderungen der Services hinterher und können die Einführung neuer Feature behindern, bis Unterstützung hinzugefügt wird.

• Emulatoren benötigen möglicherweise Support, Updates, Bugfixes oder Verbesserungen der Featureparität, für die der Autor des Emulators verantwortlich ist (bei dem es sich häufig um einen Drittanbieter handelt).

• Tests, die sich auf Emulatoren verlassen, können lokal erfolgreiche Ergebnisse liefern, sie können jedoch in der Cloud fehlschlagen aufgrund von Interaktionen mit anderen Aspekten von AWS, wie IAM-Richtlinien und Kontingenten, die im Allgemeinen nicht emuliert werden.

• Einige AWS-Services bieten keine Emulatoren an. Wenn Sie sich also nur auf die Emulation verlassen, haben Sie möglicherweise keine zufriedenstellende Testmöglichkeit für Teile Ihrer Anwendung.