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.
Verwenden von Mocked-Serviceintegrationen zum Testen in Step Functions Local
Step Functions Local wird nicht unterstützt
Step Functions Local bietet keine Funktionsparität und wird nicht unterstützt.
Sie könnten Lösungen von Drittanbietern in Betracht ziehen, die Step Functions zu Testzwecken emulieren.
In Step Functions Local können Sie die Ausführungspfade Ihrer Zustandsmaschinen testen, ohne tatsächlich integrierte Dienste aufzurufen, indem Sie simulierte Dienstintegrationen verwenden. Um Ihre Zustandsmaschinen so zu konfigurieren, dass sie simulierte Dienstintegrationen verwenden, erstellen Sie eine simulierte Konfigurationsdatei. In dieser Datei definieren Sie die gewünschte Ausgabe Ihrer Service-Integrationen als simulierte Antworten und die Ausführungen, die Ihre simulierten Antworten verwenden, um einen Ausführungspfad zu simulieren, als Testfälle.
Indem Sie Step Functions Local die Scheinkonfigurationsdatei zur Verfügung stellen, können Sie Serviceintegrationsrufe testen, indem Sie Zustandsmaschinen ausführen, die die in den Testfällen angegebenen simulierten Antworten verwenden, anstatt tatsächliche Serviceintegrationsaufrufe zu tätigen.
Anmerkung
Wenn Sie in der Mock-Konfigurationsdatei keine simulierten Serviceintegrationsantworten angeben, ruft Step Functions Local die AWS Serviceintegration mit dem Endpunkt auf, den Sie bei der Einrichtung von Step Functions Local konfiguriert haben. Informationen zur Konfiguration von Endpunkten für Step Functions Local finden Sie unterKonfigurationsoptionen für Step Functions lokal einrichten.
In diesem Thema werden mehrere Konzepte verwendet, die in der folgenden Liste definiert sind:
Mocked Service Integrations — Bezieht sich auf Aufgabenstatus, die so konfiguriert sind, dass sie simulierte Antworten verwenden, anstatt tatsächliche Serviceanfragen auszuführen.
Mocked Responses — Bezieht sich auf Scheindaten, für deren Verwendung Task-Status konfiguriert werden können.
Testfälle — Bezieht sich auf State-Machine-Ausführungen, die so konfiguriert sind, dass sie simulierte Service-Integrationen verwenden.
Vorgetäuschte Konfigurationsdatei — Bezieht sich auf eine Scheinkonfigurationsdatei, die JSON enthält. Darin werden simulierte Dienstintegrationen, simulierte Antworten und Testfälle definiert.
Konfiguration von Mocked-Serviceintegrationen
Mit Step Functions Local können Sie jede Serviceintegration simulieren. Step Functions Local erzwingt jedoch nicht, dass die Mocks mit den echten APIs identisch sind. Ein simulierter Task ruft niemals den Service-Endpunkt auf. Wenn Sie keine simulierte Antwort angeben, versucht eine Task, die Dienstendpunkte aufzurufen. Darüber hinaus generiert Step Functions Local automatisch ein Task-Token, wenn Sie eine Aufgabe mit dem simulieren.waitForTaskToken.
Schritt 1: Geben Sie Mocked Service-Integrationen in einer simulierten Konfigurationsdatei an
Sie können das Step Functions AWS SDK und optimierte Serviceintegrationen mit Step Functions Local testen. Die folgende Abbildung zeigt den Zustandsmaschine, der auf der Registerkarte State-Machine-Definition definiert ist:
Dazu müssen Sie eine simulierte Konfigurationsdatei erstellen, die Abschnitte enthält, wie unter definiert. Struktur der Scheinkonfigurationsdatei
-
Erstellen Sie eine Datei mit dem Namen
MockConfigFile.json, um Tests mit simulierten Dienstintegrationen zu konfigurieren.Das folgende Beispiel zeigt eine simulierte Konfigurationsdatei, die auf eine Zustandsmaschine mit zwei definierten Zuständen namens und verweist.
LambdaStateSQSStateSie können die
LambdaSQSIntegrationState-Machine-Definition, auf die in der Scheinkonfigurationsdatei verwiesen wird, mithilfe eines der folgenden Testfälle ausführen:-
HappyPath- Dieser Test simuliert die Ausgabe vonLambdaStateMockedSQSSuccessbzw.SQSStateunter Verwendung vonMockedLambdaSuccessund.-
Der gibt
LambdaStateden folgenden Wert zurück:"0":{ "Return":{ "StatusCode":200, "Payload":{ "StatusCode":200, "body":"Hello from Lambda!" } } } -
Das gibt
SQSStateden folgenden Wert zurück:"0":{ "Return":{ "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51", "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51" } }
-
-
RetryPath- Dieser Test simuliert die Ausgabe vonLambdaStateMockedLambdaRetryMockedSQSSuccessbzw.SQSStateunter Verwendung von. Darüber hinausLambdaStateist er so konfiguriert, dass er vier Wiederholungsversuche durchführt. Die simulierten Antworten für diese Versuche sind im Status definiert und indexiert.MockedLambdaRetry-
Der erste Versuch endet mit einem fehlgeschlagenen Task, der eine Ursache und eine Fehlermeldung enthält, wie im folgenden Beispiel dargestellt:
"0":{ "Throw": { "Error": "Lambda.ResourceNotReadyException", "Cause": "Lambda resource is not ready." } } -
Der erste und der zweite Wiederholungsversuch enden mit einem Fehler bei der Aufgabe, der eine Ursache und eine Fehlermeldung enthält, wie im folgenden Beispiel gezeigt:
"1-2":{ "Throw": { "Error": "Lambda.TimeoutException", "Cause": "Lambda timed out." } } -
Der dritte Wiederholungsversuch endet mit einem erfolgreichen Task, der das Zustandsergebnis aus dem Payload-Abschnitt in der simulierten Lambda-Antwort enthält.
"3":{ "Return": { "StatusCode": 200, "Payload": { "StatusCode": 200, "body": "Hello from Lambda!" } } }Anmerkung
Für Staaten mit einer Wiederholungsrichtlinie erschöpft Step Functions Local die in der Richtlinie festgelegten Wiederholungsversuche, bis eine erfolgreiche Antwort eingeht. Das bedeutet, dass Sie Wiederholungsversuche mit aufeinanderfolgenden Versuchsnummern kennzeichnen müssen und dass Sie alle Wiederholungsversuche abdecken müssen, bevor Sie eine erfolgreiche Antwort zurückgeben.
Wenn Sie für einen bestimmten Wiederholungsversuch keine simulierte Antwort angeben, z. B. „3" wiederholen, schlägt die Ausführung der Zustandsmaschine fehl.
-
-
HybridPath- Dieser Test simuliert die Ausgabe von.LambdaStateAfterLambdaStatewird erfolgreich ausgeführt und empfängt als Antwort simulierte Daten.SQSStateFührt einen tatsächlichen Serviceaufruf an die in der Produktion angegebene Ressource durch.
Hinweise zum Starten von Testausführungen mit simulierten Dienstintegrationen finden Sie unter. Schritt 3: Führen Sie die Mocked Service-Integrationstests durch
-
Stellen Sie sicher, dass die Struktur der simulierten Antworten der Struktur der tatsächlichen Serviceantworten entspricht, die Sie erhalten, wenn Sie integrierte Serviceanfragen tätigen. Informationen zu den strukturellen Anforderungen für gefälschte Antworten finden Sie unter. Konfiguration von Mocked-Serviceintegrationen
In der vorherigen Beispielkonfigurationsdatei sind die simulierten Antworten in der Struktur der tatsächlichen Antworten definiert, die beim Aufrufen zurückgegeben werden,
MockedLambdaSuccessundMockedLambdaRetryentsprechen dieser Struktur.HelloFromLambdaWichtig
AWS Serviceantworten können in ihrer Struktur zwischen verschiedenen Diensten variieren. Step Functions Local überprüft nicht, ob simulierte Antwortstrukturen den tatsächlichen Service-Antwortstrukturen entsprechen. Vor dem Testen müssen Sie sicherstellen, dass Ihre gefälschten Antworten den tatsächlichen Antworten entsprechen. Um die Struktur der Serviceantworten zu überprüfen, können Sie entweder die eigentlichen Serviceabrufe mithilfe von Step Functions ausführen oder die Dokumentation für diese Dienste einsehen.
Schritt 2: Stellen Sie die Mock-Konfigurationsdatei für Step Functions Local bereit
Sie können die Scheinkonfigurationsdatei auf eine der folgenden Arten für Step Functions Local bereitstellen:
Schritt 3: Führen Sie die Mocked Service-Integrationstests durch
Nachdem Sie eine Scheinkonfigurationsdatei erstellt und für Step Functions Local bereitgestellt haben, führen Sie den in der Scheinkonfigurationsdatei konfigurierten Zustandsmaschine mithilfe von simulierten Dienstintegrationen aus. Überprüfen Sie anschließend die Ausführungsergebnisse mithilfe einer API-Aktion.
-
Erstellen Sie eine Zustandsmaschine auf der Grundlage der zuvor genannten Definition in der Scheinkonfigurationsdatei.
aws stepfunctions create-state-machine \ --endpoint http://localhost:8083 \ --definition "{\"Comment\":\"Thisstatemachineiscalled:LambdaSQSIntegration\",\"StartAt\":\"LambdaState\",\"States\":{\"LambdaState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::lambda:invoke\",\"Parameters\":{\"Payload.$\":\"$\",\"FunctionName\":\"arn:aws:lambda:region:account-id:function:HelloWorldFunction\"},\"Retry\":[{\"ErrorEquals\":[\"States.ALL\"],\"IntervalSeconds\":2,\"MaxAttempts\":3,\"BackoffRate\":2}],\"Next\":\"SQSState\"},\"SQSState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::sqs:sendMessage\",\"Parameters\":{\"QueueUrl\":\"https://sqs.us-east-1.amazonaws.com/account-id/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \ --name "LambdaSQSIntegration" --role-arn "arn:aws:iam::account-id:role/service-role/LambdaSQSIntegration" -
Führen Sie die Zustandsmaschine mithilfe von simulierten Dienstintegrationen aus.
Um die Scheinkonfigurationsdatei zu verwenden, führen Sie einen
StartExecutionAPI-Aufruf auf einer Zustandsmaschine durch, die in der Scheinkonfigurationsdatei konfiguriert ist. Hängen Sie dazu das Suffix,, an den ARN der Zustandsmaschine an#, der von verwendet wird.test_nameStartExecutiontest_nameDer folgende Befehl ist ein Beispiel, das die
LambdaSQSIntegrationZustandsmaschine und die Scheinkonfiguration verwendet. In diesem Beispiel wird dieLambdaSQSIntegrationZustandsmaschine mit dem in definiertenHappyPathTest ausgeführtSchritt 1: Geben Sie Mocked Service-Integrationen in einer simulierten Konfigurationsdatei an. DerHappyPathTest enthält die Konfiguration für die Ausführung zur Verarbeitung von simulierten DienstintegrationsaufrufenLambdaStateundSQSStateZuständen, die anhand der DienstantwortenMockedLambdaSuccessundMockedSQSSuccesssimulierten Dienstantworten erfolgen.aws stepfunctions start-execution \ --endpoint http://localhost:8083 \ --name executionWithHappyPathMockedServices \ --state-machine arn:aws:states:region:account-id:stateMachine:LambdaSQSIntegration#HappyPath Zeigen Sie die Antwort auf die Ausführung der Zustandsmaschine an.
Die Antwort auf einen Aufruf
StartExecutionmithilfe eines simulierten Serviceintegrationstests entspricht der Antwort auf einenStartExecutionnormalen Aufruf, bei dem der Ausführungs-ARN und das Startdatum zurückgegeben werden.Im Folgenden finden Sie ein Beispiel für eine Antwort auf einen Aufruf
StartExecutionmit dem Mocked Service Integration Test:{ "startDate":"2022-01-28T15:03:16.981000-05:00", "executionArn":"arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices" }Überprüfen Sie die Ergebnisse der Ausführung, indem Sie einen
ListExecutionsDescribeExecution, oderGetExecutionHistoryAPI-Aufruf ausführen.aws stepfunctions get-execution-history \ --endpoint http://localhost:8083 \ --execution-arn arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServicesDas folgende Beispiel zeigt Teile einer Antwort auf einen Aufruf
GetExecutionHistoryunter Verwendung des Ausführungs-ARN aus der in Schritt 2 gezeigten Beispielantwort. In diesem BeispielSQSStatehandelt es sich bei der Ausgabe vonLambdaStateund um die Scheindaten, die inMockedLambdaSuccessundMockedSQSSuccessin der Scheinkonfigurationsdatei definiert sind. Darüber hinaus werden die simulierten Daten auf die gleiche Weise verwendet, wie Daten verwendet würden, die bei der Ausführung von tatsächlichen Serviceintegrationsaufrufen zurückgegeben werden. Außerdem wird in diesem Beispiel die Ausgabe vonLambdaStateSQSStateals Eingabe weitergegeben.{ "events": [ ... { "timestamp": "2021-12-02T19:39:48.988000+00:00", "type": "TaskStateEntered", "id": 2, "previousEventId": 0, "stateEnteredEventDetails": { "name": "LambdaState", "input": "{}", "inputDetails": { "truncated": false } } }, ... { "timestamp": "2021-11-25T23:39:10.587000+00:00", "type": "LambdaFunctionSucceeded", "id": 5, "previousEventId": 4, "lambdaFunctionSucceededEventDetails": { "output": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}", "outputDetails": { "truncated": false } } }, ... "timestamp": "2021-12-02T19:39:49.464000+00:00", "type": "TaskStateEntered", "id": 7, "previousEventId": 6, "stateEnteredEventDetails": { "name": "SQSState", "input": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}", "inputDetails": { "truncated": false } } }, ... { "timestamp": "2021-11-25T23:39:10.652000+00:00", "type": "TaskSucceeded", "id": 10, "previousEventId": 9, "taskSucceededEventDetails": { "resourceType": "sqs", "resource": "sendMessage", "output": "{\"MD5OfMessageBody\":\"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51\",\"MessageId\":\"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51\"}", "outputDetails": { "truncated": false } } }, ... ] }
Konfigurationsdatei für simulierte Serviceintegrationen in Step Functions
Step Functions Local wird nicht unterstützt
Step Functions Local bietet keine Funktionsparität und wird nicht unterstützt.
Sie könnten Lösungen von Drittanbietern in Betracht ziehen, die Step Functions zu Testzwecken emulieren.
Um simulierte Service-Integrationen zu verwenden, müssen Sie zunächst eine simulierte Konfigurationsdatei MockConfigFile.json mit dem Namen erstellen, die Ihre Scheinkonfigurationen enthält. Stellen Sie dann Step Functions Local die Scheinkonfigurationsdatei zur Verfügung. Diese Konfigurationsdatei definiert Testfälle, die Scheinzustände enthalten, die simulierte Antworten zur Serviceintegration verwenden. Der folgende Abschnitt enthält Informationen zur Struktur der Scheinkonfiguration, die die Scheinstatus und die simulierten Antworten umfasst:
Struktur der Scheinkonfigurationsdatei
Eine Scheinkonfiguration ist ein JSON-Objekt, das die folgenden Felder der obersten Ebene enthält:
-
StateMachines- Die Felder dieses Objekts stellen Zustandsmaschinen dar, die so konfiguriert sind, dass sie simulierte Dienstintegrationen verwenden. -
MockedResponse- Die Felder dieses Objekts stellen simulierte Antworten auf Aufrufe zur Serviceintegration dar.
Das Folgende ist ein Beispiel für eine simulierte Konfigurationsdatei, die eine StateMachine Definition und MockedResponse enthält.
{
"StateMachines":{
"LambdaSQSIntegration":{
"TestCases":{
"HappyPath":{
"LambdaState":"MockedLambdaSuccess",
"SQSState":"MockedSQSSuccess"
},
"RetryPath":{
"LambdaState":"MockedLambdaRetry",
"SQSState":"MockedSQSSuccess"
},
"HybridPath":{
"LambdaState":"MockedLambdaSuccess"
}
}
}
},
"MockedResponses":{
"MockedLambdaSuccess":{
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
},
"LambdaMockedResourceNotReady":{
"0":{
"Throw":{
"Error":"Lambda.ResourceNotReadyException",
"Cause":"Lambda resource is not ready."
}
}
},
"MockedSQSSuccess":{
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
},
"MockedLambdaRetry":{
"0":{
"Throw":{
"Error":"Lambda.ResourceNotReadyException",
"Cause":"Lambda resource is not ready."
}
},
"1-2":{
"Throw":{
"Error":"Lambda.TimeoutException",
"Cause":"Lambda timed out."
}
},
"3":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
}
}
}Referenz zum Feld „Scheinkonfiguration“
In den folgenden Abschnitten werden die Objektfelder der obersten Ebene erläutert, die Sie in Ihrer Scheinkonfiguration definieren müssen.
StateMachines
Das StateMachines Objekt definiert, welche Zustandsmaschinen simulierte Dienstintegrationen verwenden. Die Konfiguration für jede Zustandsmaschine wird als Feld der obersten Ebene von dargestellt. StateMachines Der Feldname ist der Name der Zustandsmaschine und der Wert ist ein Objekt, das ein einzelnes Feld mit dem Namen enthältTestCases, dessen Felder Testfälle dieses Zustandsmaschinen darstellen.
Die folgende Syntax zeigt eine Zustandsmaschine mit zwei Testfällen:
"MyStateMachine": {
"TestCases": {
"HappyPath": {
...
},
"SadPath": {
...
}
}TestCases
Die Felder von TestCases stehen für einzelne Testfälle für die Zustandsmaschine. Der Name jedes Testfalls muss pro Zustandsmaschine eindeutig sein, und der Wert jedes Testfalls ist ein Objekt, das eine simulierte Antwort angibt, die für Task-Status in der Zustandsmaschine verwendet werden soll.
Das folgende Beispiel für a TestCase verknüpft zwei Task Zustände mit zweiMockedResponses:
"HappyPath": {
"SomeTaskState": "SomeMockedResponse",
"AnotherTaskState": "AnotherMockedResponse"
}MockedResponses
MockedResponsesist ein Objekt, das mehrere simulierte Antwortobjekte mit eindeutigen Feldnamen enthält. Ein simuliertes Antwortobjekt definiert das erfolgreiche Ergebnis oder die Fehlerausgabe für jeden Aufruf eines simulierten Task-Status. Sie geben die Aufrufnummer mithilfe einzelner Ganzzahlzeichenfolgen wie „0“, „1“, „2“ und „3“ oder mithilfe eines inklusiven Bereichs von ganzen Zahlen wie „0-1“, „2-3“ an.
Wenn Sie eine Aufgabe simulieren, müssen Sie für jeden Aufruf eine simulierte Antwort angeben. Eine Antwort muss ein einzelnes Feld mit dem Namen Return oder Throw dessen Wert das Ergebnis oder die Fehlerausgabe für den simulierten Task-Aufruf enthalten. Wenn Sie keine simulierte Antwort angeben, schlägt die Ausführung der Zustandsmaschine fehl.
Im Folgenden finden Sie ein Beispiel für Return Objekte MockedResponse mit Throw und. In diesem Beispiel wird die in angegebene Antwort zurückgegeben, wenn die Zustandsmaschine zum ersten Mal ausgeführt "0-2" wird, und beim vierten Mal, wenn die Zustandsmaschine ausgeführt wird, "3" wird die in angegebene Antwort zurückgegeben.
"SomeMockedResponse": {
"0-2": {
"Throw": {
...
}
},
"3": {
"Return": {
...
}
}
}Anmerkung
Wenn Sie einen Map Status verwenden und vorhersehbare Reaktionen für diesen Map Zustand sicherstellen möchten, setzen Sie den Wert maxConcurrency auf 1. Wenn Sie einen Wert größer als 1 festlegen, führt Step Functions Local mehrere Iterationen gleichzeitig aus, wodurch die allgemeine Ausführungsreihenfolge der Zustände über Iterationen hinweg nicht vorhersehbar ist. Dies kann außerdem dazu führen, dass Step Functions Local unterschiedliche simulierte Antworten für Iterationszustände von einer Ausführung zur nächsten verwendet.
Ergebnis
Returnwird als ein Feld der Objekte dargestellt. MockedResponse Es gibt das erfolgreiche Ergebnis eines simulierten Aufgabenstatus an.
Das Folgende ist ein Beispiel für ein Return Objekt, das eine simulierte Antwort Invokeauf den Aufruf einer Lambda-Funktion enthält:
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}Wirf
Throwwird als ein Feld der MockedResponse Objekte dargestellt. Es gibt die Fehlerausgabe einer fehlgeschlagenen Aufgabe an. Der Wert von Throw muss ein Objekt sein, das Cause Felder Error und mit Zeichenfolgenwerten enthält. Darüber hinaus MockConfigFile.json muss der Zeichenkettenwert, den Sie in dem Error Feld angeben, den Fehlern entsprechen, die in den Catch Abschnitten Retry und Ihrer Zustandsmaschine behandelt wurden.
Das Folgende ist ein Beispiel für ein Throw Objekt, das eine simulierte Antwort Invokeauf den Aufruf einer Lambda-Funktion enthält:
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}