Konfiguration von Mocked-Serviceintegrationen Schritt 1: Geben Sie Mocked Service-Integrationen in einer simulierten Konfigurationsdatei an Schritt 2: Stellen Sie die Mock-Konfigurationsdatei für Step Functions Local bereit Schritt 3: Führen Sie die Mocked Service-Integrationstests durch

Verwenden von Mocked-Serviceintegrationen zum Testen in Step Functions Local

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 Antworten zur Serviceintegration angeben, ruft Step Functions Local die AWS Serviceintegration unter Verwendung des Endpunkts, den Sie bei der Einrichtung von Step Functions Local konfiguriert haben. Informationen zur Konfiguration von Endpunkten für Step Functions Local finden Sie unterEinstellung der Konfigurationsoptionen für Step Functions Local.

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.
Scheinkonfigurationsdatei — Bezieht sich auf eine simulierte KonfigurationsdateiJSON, die simulierte Dienstintegrationen, simulierte Antworten und Testfälle enthält und 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 Step Functions testen AWS SDKund optimierte Serviceintegrationen mit Step Functions Local. Die folgende Abbildung zeigt den Zustandsmaschine, der auf der Registerkarte State-Machine-Definition definiert ist:

Beispiel für die Integration eines verspotteten Dienstes.

Dazu müssen Sie eine simulierte Konfigurationsdatei erstellen, die Abschnitte enthält, wie unter definiert. Struktur der Scheinkonfigurationsdatei

Erstellen Sie eine Datei mit dem NamenMockConfigFile.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. LambdaState SQSState
Mock configuration file example
Im Folgenden finden Sie ein Beispiel für eine simulierte Konfigurationsdatei, die zeigt, wie Antworten beim Aufrufen einer Lambda-Funktion und beim Senden einer Nachricht an Amazon simuliert werden. SQS In diesem Beispiel enthält die LambdaSQSIntegrationZustandsmaschine drei Testfälle mit dem NamenHappyPath,, undRetryPath, die sich über die Task Zustände mit HybridPath dem Namen LambdaState und lustig machen. SQSState In diesen Staaten werden die Service-Antworten MockedLambdaSuccessMockedSQSSuccess, und MockedLambdaRetry Mocked Service Responses verwendet. Diese gefälschten Serviceantworten sind im MockedResponses Abschnitt der Datei definiert.
```
{
  "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!"
          }
        }
      }
    }
  }
}
```
State machine definition
Im Folgenden finden Sie ein Beispiel für eine Zustandsmaschinen-Definition mit dem Namen undLambdaSQSIntegration, die zwei Status von Serviceintegrationsaufgaben mit dem Namen LambdaState und SQSState definiert. LambdaStateenthält eine Wiederholungsrichtlinie auf States.ALL der Grundlage von.
```
{
  "Comment":"This state machine is called: LambdaSQSIntegration",
  "StartAt":"LambdaState",
  "States":{
    "LambdaState":{
      "Type":"Task",
      "Resource":"arn:aws:states:::lambda:invoke",
      "Parameters":{
        "Payload.$":"$",
        "FunctionName":"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/123456789012/myQueue",
        "MessageBody.$":"$"
      },
      "End": true
    }
  }
}
```
Sie können die LambdaSQSIntegration State-Machine-Definition, auf die in der Scheinkonfigurationsdatei verwiesen wird, mithilfe eines der folgenden Testfälle ausführen:
- HappyPath- Dieser Test simuliert die Ausgabe von LambdaState MockedSQSSuccess bzw. SQSState unter Verwendung von MockedLambdaSuccess und.
  - Der gibt LambdaState den folgenden Wert zurück:
    
    "0":{ "Return":{ "StatusCode":200, "Payload":{ "StatusCode":200, "body":"Hello from Lambda!" } } }
  - Das gibt SQSState den folgenden Wert zurück:
    
    "0":{ "Return":{ "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51", "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51" } }
- RetryPath- Dieser Test simuliert die Ausgabe von LambdaState MockedLambdaRetry MockedSQSSuccess bzw. SQSState unter Verwendung von. Darüber hinaus LambdaState ist 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. LambdaState After LambdaState wird erfolgreich ausgeführt und empfängt als Antwort simulierte Daten. SQSState Fü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, MockedLambdaSuccess und MockedLambdaRetry entsprechen dieser Struktur. HelloFromLambda

Wichtig
AWS Serviceantworten können in ihrer Struktur zwischen verschiedenen Diensten variieren. Step Functions Local überprüft nicht, ob simulierte Antwortstrukturen den tatsächlichen Service-Response-Strukturen 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:

Docker

Anmerkung

Wenn Sie die Docker-Version von Step Functions Local verwenden, können Sie die Scheinkonfigurationsdatei nur mit einer Umgebungsvariablen bereitstellen. Darüber hinaus müssen Sie die Scheinkonfigurationsdatei beim ersten Serverstart in den Step Functions Local Container mounten.

Hängen Sie die Scheinkonfigurationsdatei in ein beliebiges Verzeichnis innerhalb des Step Functions Local-Containers ein. Legen Sie dann eine Umgebungsvariable mit dem Namen SFN_MOCK_CONFIG fest, die den Pfad zur Scheinkonfigurationsdatei im Container enthält. Mit dieser Methode kann die Scheinkonfigurationsdatei beliebig benannt werden, solange die Umgebungsvariable den Dateipfad und den Namen enthält.

Der folgende Befehl zeigt das Format zum Starten des Docker-Images.


docker run -p 8083:8083 
--mount type=bind,readonly,source={absolute path to mock config file},destination=/home/StepFunctionsLocal/MockConfigFile.json 
-e SFN_MOCK_CONFIG="/home/StepFunctionsLocal/MockConfigFile.json" amazon/aws-stepfunctions-local

Im folgenden Beispiel wird der Befehl verwendet, um das Docker-Image zu starten.


docker run -p 8083:8083 
--mount type=bind,readonly,source=/Users/admin/Desktop/workplace/MockConfigFile.json,destination=/home/StepFunctionsLocal/MockConfigFile.json 
-e SFN_MOCK_CONFIG="/home/StepFunctionsLocal/MockConfigFile.json" amazon/aws-stepfunctions-local

JAR File

Verwenden Sie eine der folgenden Möglichkeiten, um die Scheinkonfigurationsdatei für Step Functions Local bereitzustellen:

Platzieren Sie die Scheinkonfigurationsdatei im selben Verzeichnis wieStep FunctionsLocal.jar. Wenn Sie diese Methode verwenden, müssen Sie der Scheinkonfigurationsdatei einen Namen gebenMockConfigFile.json.
Setzen Sie in der Sitzung, in der Step Functions Local ausgeführt wirdSFN_MOCK_CONFIG, eine Umgebungsvariable mit dem Namen, auf den vollständigen Pfad der Scheinkonfigurationsdatei. Diese Methode ermöglicht es, der Scheinkonfigurationsdatei einen beliebigen Namen zu geben, solange die Umgebungsvariable ihren Dateipfad und Namen enthält. Im folgenden Beispiel ist die SFN_MOCK_CONFIG Variable so eingestellt, dass sie auf eine simulierte Konfigurationsdatei mit dem Namen verweistEnvSpecifiedMockConfig.json, die sich im /home/workspace Verzeichnis befindet.
```
export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
```

Anmerkung

Wenn Sie Step Functions Local die Umgebungsvariable nicht SFN_MOCK_CONFIG zur Verfügung stellen, wird standardmäßig versucht, eine Scheinkonfigurationsdatei zu lesen, die MockConfigFile.json in dem Verzeichnis benannt ist, aus dem Sie Step Functions Local gestartet haben.
Wenn Sie die Scheinkonfigurationsdatei im selben Verzeichnis platzieren wie Step FunctionsLocal.jar und die Umgebungsvariable setzenSFN_MOCK_CONFIG, liest Step Functions Local die durch die Umgebungsvariable angegebene Datei.

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:us-east-1:123456789012: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/123456789012/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \
    --name "LambdaSQSIntegration" --role-arn "arn:aws:iam::123456789012:role/service-role/LambdaSQSIntegration"

Führen Sie die Zustandsmaschine mithilfe von simulierten Dienstintegrationen aus.

Um die Scheinkonfigurationsdatei zu verwenden, StartExecution API rufen Sie eine Zustandsmaschine auf, die in der Scheinkonfigurationsdatei konfiguriert ist. Hängen Sie dazu das Suffix,, an die Zustandsmaschine an#test_name, die von ARN verwendet wird. StartExecution test_nameist ein Testfall, der für den Zustandsmaschine in derselben Scheinkonfigurationsdatei konfiguriert ist.

Der folgende Befehl ist ein Beispiel, das die LambdaSQSIntegration Zustandsmaschine und die Scheinkonfiguration verwendet. In diesem Beispiel wird die LambdaSQSIntegration Zustandsmaschine mit dem in definierten HappyPath Test ausgeführtSchritt 1: Geben Sie Mocked Service-Integrationen in einer simulierten Konfigurationsdatei an. Der HappyPath Test enthält die Konfiguration für die Ausführung zur Verarbeitung von simulierten Dienstintegrationsaufrufen LambdaState und SQSState Zuständen, die anhand der Dienstantworten MockedLambdaSuccess und MockedSQSSuccess simulierten Dienstantworten erfolgen.
```
aws stepfunctions start-execution \
    --endpoint http://localhost:8083 \
    --name executionWithHappyPathMockedServices \
    --state-machine arn:aws:states:us-east-1:123456789012:stateMachine:LambdaSQSIntegration#HappyPath
```
Zeigen Sie die Antwort auf die Ausführung der Zustandsmaschine an.

Die Antwort auf einen Aufruf StartExecution mithilfe eines simulierten Serviceintegrationstests entspricht der Antwort auf einen StartExecution normalen Aufruf, bei dem das Ausführungs ARN - und das Startdatum zurückgegeben werden.

Im Folgenden finden Sie ein Beispiel für eine Antwort auf einen Aufruf StartExecution mit dem Mocked Service Integration Test:
```
{
   "startDate":"2022-01-28T15:03:16.981000-05:00",
   "executionArn":"arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```

Überprüfen Sie die Ergebnisse der Ausführung, indem Sie einen ListExecutionsDescribeExecution, oder GetExecutionHistory API -Aufruf ausführen.


aws stepfunctions get-execution-history \
    --endpoint http://localhost:8083 \
    --execution-arn arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices

Das folgende Beispiel zeigt Teile einer Antwort auf einen Aufruf GetExecutionHistory unter Verwendung der Ausführung ARN aus der in Schritt 2 gezeigten Beispielantwort. In diesem Beispiel SQSState handelt es sich bei der Ausgabe von LambdaState und um die Scheindaten, die in MockedLambdaSuccess und MockedSQSSuccess in 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 von LambdaState SQSState als 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
                }
            }
        },
        ...
    ]
}

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Tutorial: Testen mit Step Functions und AWS SAM CLILokal

Struktur der Konfigurationsdatei

Verwenden von Mocked-Serviceintegrationen zum Testen in Step Functions Local

Anmerkung

Konfiguration von Mocked-Serviceintegrationen

Schritt 1: Geben Sie Mocked Service-Integrationen in einer simulierten Konfigurationsdatei an

Anmerkung

Wichtig

Schritt 2: Stellen Sie die Mock-Konfigurationsdatei für Step Functions Local bereit

Anmerkung

Anmerkung

Schritt 3: Führen Sie die Mocked Service-Integrationstests durch