Wie man Serverless-Funktionen und Anwendungen testet

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beim Testen der Serverless-Funktionen werden herkömmliche Testtypen und -techniken verwendet. Erwägen Sie jedoch auch das Testen der Serverless-Anwendungen als Ganzes. Cloud-basierte Tests bieten das genaueste Maß für die Qualität sowohl Ihrer Funktionen als auch Ihrer Serverless-Anwendungen.

Eine Serverless-Anwendungsarchitektur umfasst verwaltete Services, die über API-Aufrufe wichtige Anwendungsfunktionen bereitstellen. Aus diesem Grund muss Ihr Entwicklungszyklus automatisierte Tests beinhalten, die bei der Interaktion Ihrer Funktionen und Services die Funktionalität überprüfen.

Wenn Sie keine cloud-basierten Tests erstellen, können aufgrund von Unterschieden zwischen Ihrer lokalen Umgebung und der bereitgestellten Umgebung Probleme auftreten. Ihr kontinuierlicher Integrationsprozess muss Tests anhand einer Reihe von Ressourcen durchführen, die in der Cloud bereitgestellt werden, bevor Ihr Code in die nächste Bereitstellungsumgebung wie QA, Staging oder Produktion übertragen wird.

Lesen Sie diesen kurzen Leitfaden weiter, um weitere Informationen zu Teststrategien für Serverless-Anwendungen zu erhalten, oder besuchen Sie das Serverless Test Samples Repository, um praktische Beispiele zu finden, die sich speziell auf die gewählte Sprache und Laufzeit beziehen.

Für serverlose Tests werden Sie weiterhin Einheiten -, Integrations - und end-to-endTests schreiben.

Gezielte Geschäftsergebnisse

Beim Testen von Serverless-Lösungen kann das Einrichten von Tests, die ereignisgesteuerte Interaktionen zwischen Services überprüfen, etwas mehr Zeit in Anspruch nehmen. Denken Sie beim Lesen dieses Leitfadens an die folgenden praktischen Geschäftsgründe:

Die Qualität einer Anwendung hängt davon ab, ob zur Überprüfung der Funktionalität verschiedene Szenarien getestet werden. Durch sorgfältiges Abwägen der Geschäftsszenarien und die Automatisierung dieser Tests für die Ausführung mit Cloud-Services lässt sich die Qualität Ihrer Anwendung erhöhen.

Softwarefehler und Konfigurationsprobleme haben die geringsten Auswirkungen auf Kosten und Zeitplan, wenn sie während eines iterativen Entwicklungszyklus entdeckt werden. Wenn Probleme während der Entwicklung unentdeckt bleiben, erfordert das Erkennen und Beheben in der Produktion mehr Aufwand durch mehr Mitarbeiter.

Eine gut geplante Serverless-Teststrategie erhöht die Softwarequalität und verbessert die Iterationszeit, indem überprüft wird, dass Ihre Lambda-Funktionen und -Anwendungen in einer Cloud-Umgebung wie erwartet funktionieren.

Was muss getestet werden?

Wir empfehlen, eine Teststrategie anzuwenden, die das Verhalten der verwalteten Services, die Cloud-Konfiguration, Sicherheitsrichtlinien und die Integration in Ihren Code testet, um die Softwarequalität zu verbessern. Verhaltenstests, auch Blackbox-Tests genannt, verifizieren, dass ein System wie erwartet funktioniert, ohne dass alle internen Daten bekannt sind.

In der traditionellen serverbasierten Architektur definieren Teams häufig einen Testumfang, der nur den Code umfasst, der auf dem Anwendungsserver ausgeführt wird. Andere Komponenten, Services oder Abhängigkeiten werden oft als extern betrachtet und liegen außerhalb des Testbereichs.

Serverless-Anwendungen bestehen oft aus kleinen Arbeitseinheiten, wie z. B. Lambda-Funktionen, die Produkte aus einer Datenbank abrufen oder Elemente aus einer Warteschlange verarbeiten oder die Größe eines Image im Speicher ändern. Jede Komponente läuft in ihrer eigenen Umgebung. Teams werden wahrscheinlich für viele dieser kleinen Einheiten innerhalb einer einzigen Anwendung zuständig sein.

Einige Anwendungsfunktionen können vollständig an verwaltete Services wie Amazon S3 delegiert oder ohne Verwendung von intern entwickeltem Code erstellt werden. Das Testen dieser verwalteten Services ist nicht erforderlich. Jedoch müssen Sie die Integration in diese Services testen.

So wird Serverless getestet

Wahrscheinlich sind Sie mit dem Testen lokal bereitgestellter Anwendungen vertraut: Sie schreiben Tests, die gegen Code laufen, der ausschließlich auf Ihrem Desktop-Betriebssystem oder in Containern ausgeführt wird. Beispielsweise können Sie eine lokale Web-Service-Komponente mit einer Anfrage aufrufen und dann Assertionen über die Antwort erstellen.

Serverless-Lösungen werden aus Ihrem Funktionscode und cloudbasierten verwalteten Services wie Warteschlangen, Datenbanken, Ereignisbussen und Messaging-Systemen erstellt. Diese Komponenten sind alle durch eine ereignisgesteuerte Architektur miteinander verbunden, in der Nachrichten, sogenannte Ereignisse, von einer Ressource zur anderen fließen. Diese Interaktionen können synchron sein, z. B. wenn ein Web-Service sofort Ergebnisse zurückgibt, oder es kann sich um eine asynchrone Aktion handeln, die zu einem späteren Zeitpunkt abgeschlossen wird, z. B. das Platzieren von Elementen in eine Warteschlange oder das Starten eines Workflow-Schritts. Ihre Teststrategie muss beide Szenarien beinhalten und die Interaktionen zwischen den Services testen. Bei asynchronen Interaktionen müssen Sie möglicherweise Nebenwirkungen in nachgeschalteten Komponenten erkennen, die möglicherweise nicht sofort beobachtbar sind.

Die Replikation einer gesamten Cloud-Umgebung, einschließlich Warteschlangen, Datenbanktabellen, Ereignisbussen, Sicherheitsrichtlinien und mehr, ist nicht praktikabel. Aufgrund der Unterschiede zwischen Ihrer lokalen Umgebung und Ihren bereitgestellten Umgebungen in der Cloud werden Sie unweigerlich auf Probleme stoßen. Die Unterschiede zwischen Ihren Umgebungen verlängern die Zeit für die Reproduktion und das Beheben von Fehlern.

Bei Serverless-Anwendungen befinden sich die Architekturkomponenten in der Regel vollständig in der Cloud, sodass Tests mit Code und Services in der Cloud notwendig sind, um Features zu entwickeln und Fehler zu beheben.

Testmethoden

In der Realität wird Ihre Teststrategie wahrscheinlich eine Mischung von Techniken beinhalten, um die Qualität Ihrer Lösungen zu erhöhen. Sie werden schnelle interaktive Tests verwenden, um Funktionen in der Konsole zu debuggen, automatisierte Einheitentests, um isolierte Geschäftslogik zu überprüfen, Verifizierung von Aufrufen externer Services mit Mocks und gelegentliche Tests gegen Emulatoren, die einen Service imitieren.

Testen in der Cloud

Das Testen in der Cloud ist für alle Testphasen nützlich, einschließlich Unit-Tests, Integrationstests und end-to-end Tests. Wenn Sie Tests mit cloud-basiertem Code durchführen, der auch mit cloud-basierten Diensten interagiert, erhalten Sie das genaueste Maß für die Qualität Ihres Codes.

Eine bequeme Möglichkeit, eine Lambda-Funktion in der Cloud auszuführen, ist ein Testereignis in der AWS Management Console. Ein Testereignis ist eine JSON-Eingabe für Ihre Funktion. Wenn Ihre Funktion keine Eingabe erfordert, kann das Ereignis ein leeres JSON-Dokument ({}) sein. Die Konsole bietet Beispielereignisse für eine Vielzahl von Service-Integrationen. Nachdem Sie ein Ereignis in der Konsole erstellt haben, können Sie es auch mit Ihrem Team teilen, um das Testen einfacher und einheitlicher zu gestalten.

Erfahren Sie, wie Sie eine Beispielfunktion in der Konsole debuggen.

Beispiele für die Testautomatisierung sind im Serverless Test Samples Repository verfügbar. Mit der folgenden Befehlszeile wird ein Beispiel für einen Python-Integrationstest automatisch ausgeführt:

python -m pytest -s tests/integration -v

Obwohl der Test lokal ausgeführt wird, interagiert er mit cloud-basierten Ressourcen. Diese Ressourcen wurden mithilfe des AWS SAM Befehlszeilentools AWS Serverless Application Model und bereitgestellt. Der Testcode ruft zunächst die bereitgestellten Stack-Ausgaben ab, zu denen der API-Endpunkt, die Funktions-ARN und die Sicherheitsrolle gehören. Als Nächstes sendet der Test eine Anfrage an den API-Endpunkt, der mit einer Liste von Amazon-S3-Buckets antwortet. Dieser Test wird ausschließlich mit cloud-basierten Ressourcen ausgeführt, um sicherzustellen, dass diese Ressourcen bereitgestellt und gesichert sind und wie erwartet funktionieren.

========================= test session starts =========================
      platform darwin -- Python 3.10.10, pytest-7.3.1, pluggy-1.0.0
      -- /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda/venv/bin/python
      cachedir: .pytest_cache
      rootdir: /Users/t/code/aws/serverless-test-samples/python-test-samples/apigw-lambda
      plugins: mock-3.10.0
      collected 1 item                                                                                                        

      tests/integration/test_api_gateway.py::TestApiGateway::test_api_gateway 

      --> Stack outputs:

        HelloWorldApi
        = https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

        PythonTestDemo
        = arn:aws:lambda:us-east-2:123456789012:function:testing-apigw-lambda-PythonTestDemo-iSij8evaTdxl
        > Hello World Lambda Function ARN

        PythonTestDemoIamRole
        = arn:aws:iam::123456789012:role/testing-apigw-lambda-PythonTestDemoRole-IZELQQ9MG4HQ
        > Implicit IAM Role created for Hello World function

      --> Found API endpoint for "testing-apigw-lambda" stack...
      --> https://p7teqs3162.execute-api.us-east-2.amazonaws.com/Prod/hello/
      API Gateway response:
      amplify-dev-123456789-deployment|myapp-prod-p-loggingbucket-123456|s3-java-bucket-123456789
      PASSED

      ========================= 1 passed in 1.53s ========================= 
      

Für die Entwicklung cloudnativer Anwendungen bietet das Testen in der Cloud die folgenden Vorteile:

Das Testen in der Cloud hat einige Nachteile. Der offensichtlichste Nachteil von Tests in der Cloud ist, dass Bereitstellungen in Cloud-Umgebungen in der Regel länger dauern als Bereitstellungen in lokalen Desktop-Umgebungen.

Zum Glück reduzieren Tools wie AWS Serverless Application Model (AWS SAM) Accelerate, AWS Cloud Development Kit (AWS CDK) Watch Mode und SST (3rd Party) die Latenz, die mit Iterationen der Cloud-Implementierung einhergeht. Diese Tools können Ihre Infrastruktur und Ihren Code überwachen und inkrementelle Updates in Ihrer Cloud-Umgebung automatisch bereitstellen.

Im Gegensatz zu lokalen Tests sind beim Testen in der Cloud weitere Ressourcen erforderlich, wodurch Servicekosten entstehen können. Die Einrichtung isolierter Testumgebungen kann die Belastung Ihrer DevOps Teams erhöhen, insbesondere in Organisationen mit strengen Kontrollen in Bezug auf Konten und Infrastruktur. Bei der Arbeit mit komplexen Infrastrukturszenarien können die Kosten für die Einrichtung und Pflege einer komplizierten lokalen Umgebung jedoch ähnlich hoch sein wie bei der Verwendung von Einweg-Testumgebungen, die mit Automatisierungstools für Infrastruktur in Form von Code erstellt werden (oder sogar höher).

Tests in der Cloud sind trotz dieser Überlegungen immer noch der beste Weg, um die Qualität Ihrer Serverless-Lösungen zu gewährleisten.

Testen mit Mocks

Das Testen mit Mocks ist eine Technik, bei der Sie Ersatzobjekte in Ihrem Code erstellen, um das Verhalten eines Cloud-Services zu simulieren.

Sie könnten beispielsweise einen Test schreiben, der ein Modell des Amazon S3-Service verwendet, der bei jedem Aufruf der CreateObjectMethode eine bestimmte Antwort zurückgibt. Wenn ein Test ausgeführt wird, gibt der Mock die programmierte Antwort zurück, ohne Amazon S3 oder andere Service-Endpunkte aufzurufen.

Mock-Objekte werden oft von einem Mock-Framework generiert, um den Entwicklungsaufwand zu reduzieren. Einige Mock-Frameworks sind generisch und andere wurden speziell dafür entwickelt AWS SDKs, wie Moto, eine Python-Bibliothek zum Mocken von AWS Diensten und Ressourcen.

Mock-Objekte unterscheiden sich von Emulatoren dadurch, dass Mocks in der Regel von einem Entwickler als Teil des Testcodes erstellt oder konfiguriert werden, wohingegen Emulatoren eigenständige Anwendungen sind, die die Funktionalität auf dieselbe Weise wie die Systeme, die sie emulieren, offenlegen.

Die Verwendung von Mocks bietet folgende Vorteile:

Mock-Tests haben die folgenden Nachteile:

Testen mit Emulation

Emulatoren sind in der Regel eine lokal ausgeführte Anwendung, die einen Produktionsdienst nachahmt. 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. Sie können beispielsweise eine Funktion mit AWS SAM local ausführen, AWS SAM um den Lambda-Dienst zu emulieren, sodass Sie schnell eine Funktion aufrufen können. Genauere Informationen finden Sie im AWS Serverless Application Model Entwicklerhandbuch unter AWS SAM lokal.

Tests mit Emulatoren bieten unter anderem folgende Vorteile:

Das Testen mit Emulatoren hat folgende Nachteile:

Bewährte Methoden

Die folgenden Abschnitte enthalten Empfehlungen für erfolgreiche Tests für Serverless-Anwendungen.

Praktische Beispiele für Tests und Testautomatisierung finden Sie im Serverless Test Samples Repository.

Priorisieren Sie Tests in der Cloud

Tests in der Cloud bieten die zuverlässigste, genaueste und vollständigste Testabdeckung. Durch die Durchführung von Tests im Kontext der Cloud werden nicht nur die Geschäftslogik, sondern auch Sicherheitsrichtlinien, Service-Konfigurationen, Kontingente und die aktuellsten API-Signaturen und Rückgabewerte umfassend getestet.

Strukturieren Sie Ihren Code zum Testen

Vereinfachen Sie Ihre Tests und Lambda-Funktionen, indem Sie Lambda-spezifischen Code von Ihrer Kerngeschäftslogik trennen.

Ihr Lambda-Funktions-Handler sollte ein schlanker Adapter sein, der Ereignisdaten aufnimmt und nur die Details an Ihre Geschäftslogikmethode(n) weiterleitet. Mit dieser Strategie können Sie umfassende Tests rund um Ihre Geschäftslogik durchführen, ohne sich über Lambda-spezifische Details Gedanken machen zu müssen. Ihre AWS Lambda-Funktionen sollten nicht die Einrichtung einer komplexen Umgebung oder einer großen Anzahl von Abhängigkeiten erfordern, um die zu testende Komponente zu erstellen und zu initialisieren.

Im Allgemeinen sollten Sie einen Handler schreiben, der Daten aus den eingehenden Ereignis- und Kontext-Objekten extrahiert und validiert und diese Eingabe dann an Methoden sendet, die Ihre Geschäftslogik ausführen.

Entwicklungs-Feedback-Schleifen beschleunigen

Es gibt Tools und Techniken, um die Entwicklungs-Feedback-Schleifen zu beschleunigen. AWS SAM Accelerate und AWS CDK Watch Mode reduzieren beispielsweise beide die Zeit, die für die Aktualisierung von Cloud-Umgebungen benötigt wird.

In den Beispielen im GitHub Serverless Test Samples-Repository werden einige dieser Techniken untersucht.

Wir empfehlen außerdem, dass Sie Cloud-Ressourcen so früh wie möglich während der Entwicklung erstellen und testen — nicht erst, nachdem Sie sich bei der Quellverwaltung angemeldet haben. Diese Praxis ermöglicht ein schnelleres Erkunden und Experimentieren bei der Entwicklung von Lösungen. Darüber hinaus hilft Ihnen die Automatisierung der Bereitstellung von einem Entwicklungscomputer aus dabei, Probleme mit der Cloud-Konfiguration schneller zu erkennen und unnötigen Aufwand für Updates und Code-Review-Prozesse zu reduzieren.

Fokus auf Integrationstests

Beim Erstellen von Anwendungen mit Lambda hat es sich bewährt, Komponenten gemeinsam zu testen.

Tests, die mit zwei oder mehr Architekturkomponenten ausgeführt werden, werden als Integrationstests bezeichnet. Das Ziel von Integrationstests besteht nicht nur darin, zu verstehen, wie Ihr Code komponentenübergreifend ausgeführt wird, sondern auch, wie sich die Umgebung, in der Ihr Code gehostet wird, verhält. End-to-end Tests sind spezielle Arten von Integrationstests, mit denen das Verhalten einer gesamten Anwendung überprüft wird.

Um Integrationstests zu erstellen, stellen Sie Ihre Anwendung in einer Cloud-Umgebung bereit. Dies kann von einer lokalen Umgebung aus oder über eine CI/CD-Pipeline erfolgen. Schreiben Sie dann Tests, um das zu testende System (SUT) zu testen und das erwartete Verhalten zu validieren.

Das zu testende System könnte beispielsweise eine Anwendung sein, die API Gateway, Lambda und DynamoDB verwendet. Ein Test könnte einen synthetischen HTTP-Aufruf an einen API-Gateway-Endpunkt ausführen und überprüfen, ob die Antwort die erwartete Nutzlast enthielt. Dieser Test bestätigt, dass der AWS Lambda-Code korrekt ist und dass jeder Dienst korrekt konfiguriert ist, um die Anfrage zu verarbeiten, einschließlich der IAM-Berechtigungen zwischen ihnen. Darüber hinaus könnten Sie den Test so gestalten, dass Datensätze unterschiedlicher Größe geschrieben werden, um zu überprüfen, ob Ihre Service-Kontingente, wie z. B. die maximale Datensatzgröße in DynamoDB, korrekt eingerichtet sind.

Erstellen Sie isolierte Testumgebungen

Tests in der Cloud erfordern in der Regel isolierte Entwicklerumgebungen, sodass sich Tests, Daten und Ereignisse nicht überschneiden.

Ein Ansatz besteht darin, jedem Entwickler ein eigenes Konto zur Verfügung zu stellen. AWS Dadurch werden Konflikte mit der Ressourcenbenennung vermieden, die auftreten können, wenn mehrere Entwickler in einer gemeinsamen Codebasis arbeiten, versuchen, Ressourcen bereitzustellen oder eine API aufzurufen.

Automatisierte Testprozesse sollten für jeden Stapel eindeutig benannte Ressourcen erstellen. Sie können beispielsweise Skripts oder TOML-Konfigurationsdateien so einrichten, dass die AWS SAM CLI sam deploy - oder sam sync-Befehle automatisch einen Stack mit einem eindeutigen Präfix angeben.

In einigen Fällen teilen sich Entwickler ein AWS Konto. Dies kann daran liegen, dass in Ihrem Stack Ressourcen vorhanden sind, deren Betrieb oder Bereitstellung und Konfiguration teuer sind. Beispielsweise kann eine Datenbank gemeinsam genutzt werden, um die korrekte Einrichtung und Bereitstellung der Daten zu vereinfachen.

Wenn Entwickler ein Konto gemeinsam nutzen, müssen Sie Grenzen festlegen, um die Inhaberschaft zu ermitteln und Überschneidungen zu vermeiden. Eine Möglichkeit, dies zu tun, besteht darin, den Stack-Namen den Entwicklerbenutzer IDs voranzustellen. Ein weiterer beliebter Ansatz ist das Einrichten von Stacks, die auf Code-Branches basieren. Aufgrund der Filialgrenzen sind die Umgebungen isoliert, aber Entwickler können dennoch Ressourcen gemeinsam nutzen, z. B. eine relationale Datenbank. Dieser Ansatz ist eine bewährte Methode, wenn Entwickler an mehr als einer Verzweigung gleichzeitig arbeiten.

Das Testen in der Cloud ist für alle Testphasen wertvoll, einschließlich Unit-Tests, Integrationstests und end-to-end Tests. Das Aufrechterhalten einer ordnungsgemäßen Isolierung ist von entscheidender Bedeutung. Dennoch sollten Sie darauf achten, dass Ihre QA-Umgebung der Produktionsumgebung so nahe wie möglich kommt. Aus diesem Grund fügen Teams den QA-Umgebungen Änderungssteuerungsvorgänge hinzu.

In Vorproduktions- und Produktionsumgebungen werden die Grenzen in der Regel auf Kontoebene gezogen, um Arbeitslasten von „Noisy-Neighbor“-Problemen zu isolieren und Sicherheitskontrollen mit geringsten Berechtigungen zum Schutz sensibler Daten zu implementieren. Für Workloads gibt es Kontingente. Ihre Tests dürfen weder die für die Produktion zugewiesenen Kontingente verbrauchen („Noisy Neighbor“) noch Zugriff auf Kundendaten haben. Lasttests sind eine weitere Aktivität, die Sie von Ihrem Produktions-Stack isolieren sollten.

In jedem Fall müssen die Umgebungen mit Warnungen und Kontrollen konfiguriert werden, um unnötige Ausgaben zu vermeiden. Sie können beispielsweise die Art, Stufe oder Größe der Ressourcen einschränken, die erstellt werden können, und E-Mail-Benachrichtigungen einrichten, wenn die geschätzten Kosten einen bestimmten Schwellenwert überschreiten.

Mocks für isolierte Geschäftslogik verwenden

Mock-Frameworks sind ein wertvolles Tool zum Schreiben schneller Einheitentests. Sie sind besonders nützlich, wenn Tests komplexe interne Geschäftslogiken wie mathematische oder finanzielle Berechnungen oder Simulationen abdecken. Suchen Sie nach Einheitentests, die eine große Anzahl von Testfällen oder Eingabevariationen enthalten, bei denen diese Eingaben das Muster oder den Inhalt von Aufrufen an andere Cloud-Services nicht ändern.

Code, der durch Komponententests mit Mocks abgedeckt wird, muss auch durch Tests in der Cloud abgedeckt werden. Dies wird empfohlen, da ein Entwickler-Laptop oder eine Build-Machine-Umgebung anders konfiguriert werden kann als eine Produktionsumgebung in der Cloud. Beispielsweise beanspruchen Ihre Lambda-Funktionen möglicherweise mehr Speicher oder Zeit als zugewiesen, wenn sie mit bestimmten Eingabeparametern ausgeführt werden. Möglicherweise enthält Ihr Code auch Umgebungsvariablen, die nicht auf die gleiche Weise (oder überhaupt nicht) konfiguriert sind, und die Unterschiede könnten dazu führen, dass sich der Code anders verhält oder fehlschlägt.

Der Nutzen von Mocks ist bei Integrationstests geringer, da der Aufwand zur Implementierung der erforderlichen Mocks mit der Anzahl der Verbindungspunkte zunimmt. End-to-endBeim Testen sollten keine Mocks verwendet werden, da sich diese Tests im Allgemeinen mit Zuständen und komplexer Logik befassen, die mit Schein-Frameworks nicht einfach simuliert werden können.

Vermeiden Sie schließlich die Verwendung von nachgebildeten Cloud-Services, um die ordnungsgemäße Implementierung von Service-Aufrufen zu überprüfen. Führen Sie stattdessen Cloud-Service-Aufrufe in der Cloud durch, um Verhalten, Konfiguration und funktionale Implementierung zu überprüfen.

Emulatoren sparsam verwenden

Emulatoren können für einige Anwendungsfälle praktisch sein, z. B. für ein Entwicklungsteam mit begrenztem, unzuverlässigem oder langsamem Internetzugang. In den meisten Fällen sollten Sie Emulatoren jedoch sparsam verwenden.

Wenn Sie Emulatoren vermeiden, können Sie mit den neuesten Servicefunktionen und auf dem neuesten Stand arbeiten und Innovationen entwickeln. APIs Sie werden nicht auf die Veröffentlichung von Anbietern warten müssen, um die Featureparität zu erreichen. Sie reduzieren Ihre Vorabkosten und laufenden Kosten für den Kauf und die Konfiguration mehrerer Entwicklungssysteme und bauen Maschinen. Darüber hinaus vermeiden Sie das Problem, dass bei vielen Cloud-Services einfach keine Emulatoren verfügbar sind. Eine Teststrategie, die auf Emulation basiert, macht es unmöglich, diese Services zu nutzen (was zu potenziell teureren Problemumgehungen führt) oder Code und Konfigurationen zu erstellen, die nicht gut getestet wurden.

Wenn Sie die Emulation zum Testen verwenden, müssen Sie dennoch in der Cloud testen, um die Konfiguration zu überprüfen und Interaktionen mit Cloud-Diensten zu testen, die in einer emulierten Umgebung nur simuliert oder nachgeahmt werden können.

Herausforderungen beim Testen vor Ort

Wenn Sie Emulatoren und simulierte Aufrufe verwenden, um auf Ihrem lokalen Desktop zu testen, können Testinkonsistenzen auftreten, wenn Ihr Code in Ihrer CI/CD-Pipeline von Umgebung zu Umgebung fortschreitet. Einheitentests zur Validierung der Geschäftslogik Ihrer Anwendung auf Ihrem Desktop testen möglicherweise wichtige Aspekte der Cloud-Services nicht genau.

Die folgenden Beispiele zeigen, worauf beim lokalen Testen mit Mocks und Emulatoren zu achten ist:

Beispiel: Die Lambda-Funktion erstellt einen S3-Bucket

Wenn die Logik einer Lambda-Funktion von der Erstellung eines S3-Buckets abhängt, sollte ein vollständiger Test bestätigen, dass Amazon S3 aufgerufen und der Bucket erfolgreich erstellt wurde.

Die Mock- und Emulations-Setups testen, was die Lambda-Funktion tut, wenn sie Amazon S3 aufruft. Diese Tests überprüfen jedoch nicht, ob die Lambda-Funktion, wie konfiguriert, in der Lage ist, den Amazon-S3-Bucket erfolgreich zu erstellen. Sie müssen sicherstellen, dass der Rolle, die der Funktion zugewiesen ist, eine Sicherheitsrichtlinie angehängt ist, die es der Funktion ermöglicht, die s3:CreateBucket-Aktion auszuführen. Andernfalls schlägt die Funktion wahrscheinlich fehl, wenn sie in einer Cloud-Umgebung bereitgestellt wird.

Beispiel: Verwenden Sie eine Lambda-Funktion, um Nachrichten aus einer Amazon-SQS-Warteschlange zu verarbeiten.

Wenn eine Amazon-SQS-Warteschlange die Quelle einer Lambda-Funktion ist, muss durch einen vollständigen Test überprüft werden, ob die Lambda-Funktion erfolgreich aufgerufen wird, wenn eine Nachricht in eine Warteschlange gestellt wird.

Emulationstests und Mock-Tests werden in der Regel so eingerichtet, dass der Lambda-Funktionscode direkt ausgeführt wird und die Amazon-SQS-Integration simuliert wird, indem eine JSON-Event-Payload (oder ein deserialisiertes Objekt) als Eingabe des Funktions-Handlers übergeben wird.

Bei lokalen Tests, bei denen die Amazon-SQS-Integration simuliert wird, wird getestet, was die Lambda-Funktion tut, wenn sie von Amazon SQS mit einer bestimmten Nutzlast aufgerufen wird. Der Test bestätigt jedoch nicht, dass Amazon SQS die Lambda-Funktion erfolgreich aufruft, wenn sie in einer Cloud-Umgebung bereitgestellt wird.

Einige Beispiele für Konfigurationsprobleme, die bei Amazon SQS und Lambda auftreten können, sind die folgenden:

Wie diese Beispiele zeigen, liefern Tests, die sich mit der Geschäftslogik, aber nicht mit den Konfigurationen zwischen Cloud-Services befassen, wahrscheinlich zu unzuverlässigen Ergebnissen.

Häufig gestellte Fragen

Ich habe eine Lambda-Funktion, die Berechnungen durchführt und ein Ergebnis zurückgibt, ohne andere Dienste aufzurufen. Muss ich es wirklich in der Cloud testen?

Ja. Lambda-Funktionen haben Konfigurationsparameter, die das Testergebnis verändern könnten. Der gesamte Lambda-Funktionscode ist von Timeout- und Speichereinstellungen abhängig, was dazu führen kann, dass die Funktion fehlschlägt, wenn diese Einstellungen nicht richtig gesetzt sind. Lambda-Richtlinien ermöglichen auch die Standardausgabeprotokollierung an Amazon CloudWatch. Auch wenn Ihr Code nicht CloudWatch direkt aufruft, ist eine Genehmigung erforderlich, um die Protokollierung zu aktivieren. Diese erforderliche Erlaubnis kann nicht korrekt verspottet oder nachgeahmt werden.

Wie können Tests in der Cloud beim Einheitentest helfen? Wenn es sich in der Cloud befindet und eine Verbindung zu anderen Ressourcen herstellt, ist das nicht ein Integrationstest?

Wir definieren Komponententests als Tests, die isoliert auf Architekturkomponenten ausgeführt werden. Dies hindert Tests jedoch nicht daran, Komponenten einzubeziehen, die möglicherweise andere Services aufrufen oder Netzwerkkommunikation nutzen.

Viele Serverless-Anwendungen verfügen über Architekturkomponenten, die isoliert getestet werden können, sogar in der Cloud. Ein Beispiel ist eine Lambda-Funktion, um Eingaben entgegenzunehmen, die Daten zu verarbeiten und eine Nachricht an eine Amazon-SQS-Warteschlange zu senden. Ein Komponententest dieser Funktion würde wahrscheinlich testen, ob Eingabewerte dazu führen, dass bestimmte Werte in der Nachricht in der Warteschlange vorhanden sind.

Stellen Sie sich einen Test vor, der nach dem Muster „Arrange, Act, Assert“ geschrieben wurde:

Ein Mock-Testansatz würde das Mocking der Warteschlange mit einem prozessinternen Mock-Objekt und das Erstellen einer prozessinternen Instance der Klasse oder des Moduls, das den Lambda-Funktionscode enthält, beinhalten. Während der Assert-Phase würde die Nachricht in der Warteschlange aus dem simulierten Objekt abgerufen.

Bei einem cloud-basierten Ansatz würde der Test eine Amazon-SQS-Warteschlange für die Testzwecke erstellen und die Lambda-Funktion mit Umgebungsvariablen bereitstellen, die so konfiguriert sind, dass sie die isolierte Amazon-SQS-Warteschlange als Ausgabeziel verwenden. Nach dem Ausführen der Lambda-Funktion würde der Test die Nachricht aus der Amazon-SQS-Warteschlange abrufen.

Der cloud-basierte Test würde denselben Code ausführen, dasselbe Verhalten bestätigen und die funktionale Korrektheit der Anwendung überprüfen. Er hätte jedoch den zusätzlichen Vorteil, dass die Einstellungen der Lambda-Funktion validiert werden könnten: die IAM-Rolle, die IAM-Richtlinien sowie die Timeout- und Speichereinstellungen der Funktion.

Nächste Schritte und Ressourcen

Verwenden Sie die folgenden Ressourcen, um weitere Informationen und praktische Testbeispiele zu erhalten.

Beispielimplementierungen

Das Serverless Test Samples Repository on GitHub enthält konkrete Beispiele für Tests, die den in diesem Handbuch beschriebenen Mustern und bewährten Methoden folgen. Das Repository enthält Beispielcode und Anleitungen zu den Mock-, Emulations- und Cloud-Testprozessen, die in den vorherigen Abschnitten beschrieben wurden. Verwenden Sie dieses Repository, um sich über die neuesten Anleitungen zu serverlosen Tests von auf dem Laufenden zu halten. AWS

Weitere Informationen

Besuchen Sie Serverless Land, um auf die neuesten Blogs, Videos und Schulungen für AWS serverlose Technologien zuzugreifen.

Es wird auch empfohlen, die folgenden AWS Blogbeiträge zu lesen:

Tools