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. Sie können beispielsweise einen Test schreiben, der ein Modell des Amazon S3 S3-Service verwendet, und Sie können dieses Modell so konfigurieren, dass bei jedem Aufruf der CreateObjectMethode ein bestimmtes Antwortobjekt zurückgegeben wird. 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 Schein-Frameworks sind generisch und andere wurden speziell dafür entwickelt AWS SDKs.

Mocks fallen zusammen mit Stummeln in die breitere Kategorie von Fälschungen. Mocks unterscheiden sich von Emulatoren (auf die weiter unten in diesem Abschnitt eingegangen wird) dadurch, dass Mocks in der Regel von einem Entwickler als Teil des Testcodes erstellt oder konfiguriert werden, wohingegen Emulatoren eigenständige Anwendungen sind, die APIs (wie REST APIs) auf die gleiche Weise verfügbar gemacht werden wie die Systeme, die sie emulieren.

Die Verwendung von Mocks bietet folgende Vorteile:

• Mocks kann Dienste von Drittanbietern simulieren, auf die Ihre Anwendung keinen Einfluss hat, z. B. SaaS-Anbieter (Software as a Service), ohne direkten Zugriff auf diese Dienste zu benötigen. APIs

• 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.

• Wenn neue Funktionen oder Verhaltensweisen verfügbar werden, können Mock-Tests schneller reagieren, indem sie ein generisches Mock-Framework verwenden (oder darauf zurückgreifen), das die neuen Funktionen 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 Werte 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 weiterentwickelt werden oder die getestete Anwendungslogik erweitert wird, um neue Aufrufe zu tätigen. APIs 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.

• Schein-Frameworks, genau wie Emulatoren, sind in Bezug auf das Testen oder Erkennen AWS Identity and Access Management (IAM) von 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. Zum Beispiel:

• Sie können Tests in der Cloud anhand der neuesten Werte APIs und Rückgabewerte 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 Anforderung, 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 ausgeführte Anwendungen, sogenannte Emulatoren, ermöglicht, die Diensten ähneln. AWS Emulatoren haben ähnliche APIs Eigenschaften wie ihre Cloud-Gegenstücke und liefern ähnliche Rückgabewerte. Sie können auch Zustandsänderungen simulieren, die durch API-Aufrufe initiiert werden. Beispielsweise könnte ein Amazon S3 S3-Emulator ein Objekt auf der lokalen Festplatte speichern, wenn die PutObjectMethode aufgerufen wird. Wenn GetObjectes 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 Funktionen hinken APIs in der Regel den Änderungen der Dienste hinterher und können die Einführung neuer Funktionen 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 auf Emulatoren basieren, können lokal zu erfolgreichen Ergebnissen führen, in der Cloud können sie jedoch aufgrund von Interaktionen mit anderen Aspekten AWS wie IAM-Richtlinien und -Kontingenten fehlschlagen, die im Allgemeinen nicht emuliert werden.

• Für einige AWS Dienste sind keine Emulatoren verfügbar. Wenn Sie sich also nur auf Emulation verlassen, haben Sie möglicherweise keine zufriedenstellende Testoption für Teile Ihrer Anwendung.