Testtechniken für Serverless-Anwendungen

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

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.

Scheintests können lokal erfolgreich sein, schlagen aber in der Cloud fehl, weil sie das Verhalten realer Dienste simulieren — und nicht replizieren —, sodass umgebungsspezifische Probleme unentdeckt bleiben.

Schein-Frameworks können ebenso wie Emulatoren keine AWS Identity and Access Management (IAM-) Richtlinienverstöße, Servicekontingentbeschränkungen oder Beschränkungen der Nutzlastgröße erkennen und lösen auch keine Zusatzdienste wie Amazon oder Amazon aus CloudWatch AWS CloudTrail, GuardDuty die das Anwendungsverhalten in einer bereitgestellten Umgebung beeinflussen können.

Obwohl Mocks besser simulieren können, was eine Anwendung tun wird, wenn die Autorisierung fehlschlägt oder ein Kontingent überschritten wird, kann anhand von Scheintests nicht festgestellt werden, welches Ergebnis tatsächlich eintritt, wenn der Code in der Produktionsumgebung bereitgestellt wird.

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 vertraut sind, haben Sie möglicherweise eine Datenbank-Engine und einen Webserver, ähnlich denen, die in der Produktion laufen, auf Ihrem lokalen Computer ausgeführt, um schnelle, lokale, isolierte Testfunktionen bereitzustellen.

Da keine Änderungen an der Cloud-Infrastruktur (wie Cloud-Konten für Entwickler) erforderlich sind, ist die Implementierung mit bestehenden Testmustern einfach. Emulationstests bieten die Vorteile schneller, lokaler Entwicklungsiterationen.

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.

In einigen AWS-Services Fällen 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.

Sie können Tests in der Cloud mit den neuesten Funktionen APIs und Dienstfunktionen durchführen und so sicherstellen, dass Ihre Tests die neuesten Rückgabewerte und Verhaltensweisen widerspiegeln, während AWS ständig neue Dienste und Funktionen eingeführt werden.

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.

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. 

In regulierten Branchen können Unternehmenssicherheitsrichtlinien den Zugriff von Entwicklern auf Cloud-Umgebungen einschränken, was es schwierig oder unmöglich macht, Cloud-Tests als Teil eines lokalen Entwicklungsworkflows durchzuführen.

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.