So testen Sie serverlose Funktionen und Anwendungen

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 serverlose Anwendungsarchitektur umfasst verwaltete Dienste, die wichtige Anwendungsfunktionen über API Aufrufe 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.

• Einheitentests — Tests, die an einem isolierten Codeblock ausgeführt werden. Zum Beispiel die Überprüfung der Geschäftslogik zur Berechnung der Bereitstellungskosten für einen bestimmten Artikel und Bestimmungsort.

• Integrationstests — Tests, an denen zwei oder mehr Komponenten oder Dienste beteiligt sind, die interagieren, in der Regel in einer Cloud-Umgebung. Bei der Überprüfung einer Funktion werden beispielsweise Ereignisse aus einer Warteschlange verarbeitet.

• nd-to-end E-Tests — Tests, die das Verhalten einer gesamten Anwendung überprüfen. Stellen Sie beispielsweise sicher, dass die Infrastruktur korrekt eingerichtet ist und die Ereignisse zwischen den Services wie erwartet ablaufen, um die Bestellungen der Kunden aufzuzeichnen.

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:

• Erhöhen Sie die Qualität Ihrer Anwendung

• Verkürzen Sie die Zeit für das Entwickeln von Features und das Beheben von Fehlern

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.

• Führen Sie Einheitentests durch, um die Geschäftslogik innerhalb der Lambda-Funktionen zu überprüfen.

• Stellen Sie sicher, dass die integrierten Services tatsächlich aufgerufen werden und die Eingabeparameter korrekt sind.

• Stellen Sie sicher, dass ein Ereignis alle erwarteten Dienste end-to-end in einem Workflow durchläuft.

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 Webdienst sofort Ergebnisse zurückgibt, oder eine asynchrone Aktion, 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 — Sie stellen Infrastruktur und Code bereit, um mit tatsächlichen Services, Sicherheitsrichtlinien, Konfigurationen und infrastrukturspezifischen Parametern zu testen. Cloud-basierte Tests bieten das genaueste Maß für die Qualität Ihres Codes.

  Das Debuggen einer Funktion in der Konsole ist eine schnelle Möglichkeit, in der Cloud zu testen. Sie können aus einer Bibliothek mit Beispieltestereignissen wählen oder ein benutzerdefiniertes Ereignis erstellen, um eine Funktion isoliert zu testen. Sie können die Testereignisse auch über die Konsole mit Ihrem Team teilen.

  Um das Testen während des Entwicklungs- und Build-Lebenszyklus zu automatisieren, müssen Sie außerhalb der Konsole testen. In den Abschnitten zum sprachspezifischen Testen in diesem Handbuch finden Sie Automatisierungsstrategien und Ressourcen.

• Testen mit Mocks (auch Fakes genannt) — Mocks sind Objekte in Ihrem Code, die einen externen Dienst simulieren und diesen repräsentieren. Mocks bieten vordefiniertes Verhalten zur Überprüfung von Service-Aufrufen und Parametern. Ein Fake ist eine Scheinimplementierung, die Abkürzungen verwendet, um die Leistung zu vereinfachen oder zu verbessern. Beispielsweise könnte ein gefälschtes Datenzugriffsobjekt Daten aus einem In-Memory-Datenspeicher zurückgeben. Mocks können komplexe Abhängigkeiten nachahmen und vereinfachen, können aber auch zu weiteren Mocks führen, um verschachtelte Abhängigkeiten zu ersetzen.

• Testen mit Emulatoren — Sie können Anwendungen (manchmal von Drittanbietern) einrichten, um einen Cloud-Dienst in Ihrer lokalen Umgebung nachzuahmen. Geschwindigkeit ist ihre Stärke, aber die Einrichtung und die Parität mit Produktions-Services ist ihre Schwäche. Verwenden Sie Emulatoren sparsam.

Testen in der Cloud

Das Testen in der Cloud ist für alle Testphasen nützlich, einschließlich Komponententests, 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 für Ihre Funktion keine Eingabe erforderlich ist, 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.

Anmerkung

Obwohl das Ausführen von Funktionen in der Konsole eine schnelle Möglichkeit zum Debuggen ist, ist die Automatisierung Ihrer Testzyklen unerlässlich, um die Anwendungsqualität und die Entwicklungsgeschwindigkeit zu erhöhen.

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, die den API Endpunkt, die Funktion ARN und die Sicherheitsrolle enthalten. Als Nächstes sendet der Test eine Anfrage an den API Endpunkt, der mit einer Liste von Amazon S3 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-west-2.amazonaws.com/Prod/hello/
        > API Gateway endpoint URL for Prod stage for Hello World function

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

        PythonTestDemoIamRole
        = arn:aws:iam::1234567890: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-west-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:

• Sie können jeden verfügbaren Service testen.

• Sie verwenden immer die neuesten Service APIs - und Rückgabewerte.

• Eine Cloud-Testumgebung ähnelt stark Ihrer Produktionsumgebung.

• Tests können Sicherheitsrichtlinien, Service Quotas, Konfigurationen und infrastrukturspezifische Parameter umfassen.

• Jeder Entwickler kann schnell eine oder mehrere Testumgebungen in der Cloud erstellen.

• Cloud-Tests erhöhen die Sicherheit, dass Ihr Code in der Produktion korrekt ausgeführt wird.

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(Drittanbieter) 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.

Anmerkung

Erfahren Sie im Serverless Developer Guide, wie Sie Infrastruktur als Code erstellen, um mehr über AWS Serverless Application Model, AWS CloudFormation und zu erfahren. AWS Cloud Development Kit (AWS CDK)

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:

• 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 nützlich für das Testen von Fehlerbedingungen, insbesondere wenn solche Bedingungen schwer zu simulieren sind, wie z. B. ein Service-Ausfall.

• Mocks können nach der Konfiguration schnelle lokale Tests 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 Features oder Verhaltensweisen verfügbar werden, können Mock-Tests schneller reagieren. Mithilfe eines generischen Mock-Frameworks können Sie neue Funktionen simulieren, sobald die Updates AWS SDK verfügbar sind.

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.

• Mocks werden von Entwicklern geschrieben, konfiguriert und müssen von ihnen gewartet werden, was ihre Verantwortung erhöht.

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

• Mocks können schwierig zu warten sein. Wenn sich simulierte API Cloud-Signaturen ändern oder Rückgabewertschemata weiterentwickelt werden, müssen Sie Ihre Mocks aktualisieren. Mocks erfordern auch Aktualisierungen, wenn Sie Ihre Anwendungslogik erweitern, um neue Aufrufe zu tätigen. APIs

• Tests, die Mocks verwenden, können in Desktop-Umgebungen erfolgreich sein, in der Cloud jedoch fehlschlagen. Die Ergebnisse stimmen möglicherweise nicht mit den aktuellen API Ergebnissen überein. Die Servicekonfiguration und die Kontingente können nicht getestet werden.

• Schein-Frameworks können Richtlinien oder Kontingentbeschränkungen für AWS Identity and Access Management (IAM) nur begrenzt testen oder erkennen. Mocks können zwar besser simulieren, wenn die Autorisierung fehlschlägt oder ein Kontingent überschritten wird, aber Tests können nicht bestimmen, welches Ergebnis in einer Produktionsumgebung tatsächlich eintreten wird.

Testen mit Emulation

Emulatoren sind in der Regel eine lokal ausgeführte Anwendung, die einen AWS Produktionsdienst nachahmt.

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 ausgelöst 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:

• Emulatoren können schnelle lokale Entwicklungsiterationen und Tests ermöglichen.

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

• Emulatoren erfordern keine Änderungen an der Cloud-Infrastruktur (z. B. Cloud-Konten für Entwickler), sodass sie einfach mit vorhandenen Testmustern implementiert werden können.

Das Testen mit Emulatoren hat folgende Nachteile:

• Emulatoren können schwierig einzurichten und zu replizieren sein, insbesondere wenn sie in CI/CD-Pipelines verwendet werden. Dies kann den Workload von IT-Mitarbeitern oder Entwicklern erhöhen, die ihre eigene Software verwalten.

• Emulierte Funktionen und hinken APIs in der Regel den Service-Updates hinterher. Dies kann zu Fehlern führen, da der getestete Code nicht mit dem tatsächlichen API Code übereinstimmt und die Einführung neuer Funktionen behindert.

• Emulatoren benötigen Unterstützung, Updates, Bugfixes und Verbesserungen der Featureparität. Diese liegen in der Verantwortung des Emulatorautors, bei dem es sich um ein Drittunternehmen handeln kann.

• Tests, die auf Emulatoren basieren, können lokal zu erfolgreichen Ergebnissen führen, schlagen in der Cloud jedoch aufgrund von Produktionssicherheitsrichtlinien, dienstübergreifenden Konfigurationen oder der Überschreitung von Lambda-Kontingenten fehl.

• Für viele AWS Dienste sind keine Emulatoren verfügbar. Wenn Sie sich auf Emulation verlassen, steht Ihnen möglicherweise keine zufriedenstellende Testoption für Teile Ihrer Anwendung zur Verfügung.

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 Cloud-Kontext werden nicht nur die Geschäftslogik, sondern auch Sicherheitsrichtlinien, Dienstkonfigurationen, 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. Beispielsweise verringern sowohl der AWS SAMAccelerate - als auch der AWS CDKWatch-Modus den Zeitaufwand für die Aktualisierung von Cloud-Umgebungen.

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 der Integrationstests besteht darin, nicht nur zu verstehen, wie Ihr Code komponentenübergreifend ausgeführt wird, sondern auch, wie sich die Umgebung, in der Ihr Code gehostet wird, verhält. nd-to-end E-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 überprüfen.

Bei dem getesteten System könnte es sich beispielsweise um eine Anwendung handeln, die API Gateway, Lambda und DynamoDB verwendet. Ein Test könnte einen synthetischen HTTP Aufruf an einen API Gateway-Endpunkt tätigen und überprüfen, ob die Antwort die erwartete Nutzlast enthält. 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 AWS Konto zur Verfügung zu stellen. Dadurch werden Konflikte bei der Benennung von Ressourcen 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 Befehle AWS SAM CLI sam deploy oder sam sync 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 für die Implementierung der notwendigen Mocks mit der Anzahl der Verbindungspunkte steigt. Beim nd-to-end Testen von E sollten keine Mocks verwendet werden, da sich diese Tests im Allgemeinen mit Zuständen und komplexer Logik befassen, die mit Mock-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.

• In einem Test-Setup können Sie eine Erfolgsreaktion simulieren und möglicherweise einen Testfall hinzufügen, um eine Fehlerreaktion zu behandeln.

• In einem Emulationstestszenario CreateBucketAPIkann der aufgerufen werden, aber Sie müssen sich bewusst sein, dass die Identität, die den lokalen Anruf tätigt, nicht vom Lambda-Dienst stammt. Die Anrufindentität übernimmt keine Sicherheitsrolle wie in der Cloud. Daher wird stattdessen eine Platzhalterauthentifizierung verwendet, möglicherweise mit einer permissiveren Rolle oder Benutzeridentität, die bei Ausführung in der Cloud anders sein wird.

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: Die Lambda-Funktion verarbeitet Nachrichten aus einer Amazon-Warteschlange SQS

Wenn eine SQS Amazon-Warteschlange die Quelle einer Lambda-Funktion ist, sollte ein vollständiger Test sicherstellen, dass die Lambda-Funktion erfolgreich aufgerufen wird, wenn eine Nachricht in eine Warteschlange gestellt wird.

Emulationstests und Scheintests sind im Allgemeinen so eingerichtet, dass der Lambda-Funktionscode direkt ausgeführt wird und die SQS Amazon-Integration simuliert wird, indem eine JSON Event-Payload (oder ein deserialisiertes Objekt) als Eingabe des Funktionshandlers übergeben wird.

Lokale Tests, die die SQS Amazon-Integration simulieren, testen, was die Lambda-Funktion tut, wenn sie von Amazon SQS mit einer bestimmten Nutzlast aufgerufen wird. Der Test überprüft jedoch nicht, ob Amazon die Lambda-Funktion erfolgreich aufruft, wenn sie in einer Cloud-Umgebung bereitgestellt SQS wird.

Einige Beispiele für Konfigurationsprobleme, auf die Sie bei Amazon SQS und Lambda stoßen könnten, sind die folgenden:

• Das Amazon SQS Visibility Timeout ist zu niedrig, was zu mehreren Aufrufen führt, obwohl nur einer beabsichtigt war.

• Die Ausführungsrolle der Lambda-Funktion erlaubt es nicht, Nachrichten aus der Warteschlange zu lesen (durch sqs:ReceiveMessage,sqs:DeleteMessage, oder sqs:GetQueueAttributes).

• Das Beispielereignis, das an die Lambda-Funktion übergeben wird, überschreitet das SQS Amazon-Nachrichtengrößenkontingent. Daher ist der Test ungültig, da Amazon niemals in der Lage SQS wäre, eine Nachricht dieser Größe zu senden.

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.

FAQ

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 eingestellt 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, die Eingaben entgegennimmt, die Daten verarbeitet und eine Nachricht an eine SQS Amazon-Warteschlange sendet. 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:

• Arrange: Zuweisung von Ressourcen (eine Warteschlange zum Empfang von Nachrichten und die zu testende Funktion).

• Act: Aufrufen der zu testenden Funktion.

• Assert: Abrufen der von der Funktion gesendeten Nachricht und Validieren der Ausgabe.

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 SQS Amazon-Warteschlange für die Zwecke des Tests erstellen und die Lambda-Funktion mit Umgebungsvariablen bereitstellen, die so konfiguriert sind, dass sie die isolierte SQS Amazon-Warteschlange als Ausgabeziel verwenden. Nach dem Ausführen der Lambda-Funktion würde der Test die Nachricht aus der SQS Amazon-Warteschlange abrufen.

Der cloud-basierte Test würde denselben Code ausführen, dasselbe Verhalten bestätigen und die funktionale Korrektheit der Anwendung überprüfen. Es 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 Repository Serverless Test Samples on GitHub enthält konkrete Beispiele für Tests, die den in diesem Leitfaden 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:

• Beschleunigen Sie die serverlose Entwicklung mit AWS SAM Accelerate (AWS Blogbeitrag)

• Steigerung der Entwicklungsgeschwindigkeit mit CDK Watch (AWS Blogbeitrag)

• Verspottung der Serviceintegrationen mit AWS Step Functions Local (AWS Blogbeitrag)

• Erste Schritte beim Testen serverloser Anwendungen (Blogbeitrag)AWS

Tools

• AWS SAM — Testen und Debuggen serverloser Anwendungen

• AWS SAM — Integration mit automatisierten Tests

• Lambda — Testen von Lambda-Funktionen mit Hilfe der Lambda-Konsole