Utilisation d'intégrations de services simulées pour les tests dans Step Functions Local

Dans Step Functions Local, vous pouvez tester les chemins d'exécution de vos machines d'état sans réellement appeler de services intégrés en utilisant des intégrations de services simulées. Pour configurer vos machines d'état afin d'utiliser des intégrations de services simulées, vous devez créer un fichier de configuration fictif. Dans ce fichier, vous définissez le résultat souhaité de vos intégrations de services sous forme de réponses simulées et les exécutions qui utilisent vos réponses simulées pour simuler un chemin d'exécution sous forme de cas de test.

En fournissant le fichier de configuration fictif à Step Functions Local, vous pouvez tester les appels d'intégration de services en exécutant des machines d'état qui utilisent les réponses simulées spécifiées dans les scénarios de test au lieu de passer de véritables appels d'intégration de services.

Cette rubrique utilise plusieurs concepts définis dans la liste suivante :

Configuration d'intégrations de services simulées

Vous pouvez simuler n'importe quelle intégration de service à l'aide de Step Functions Local. Cependant, Step Functions Local n'impose pas que les maquettes soient identiques aux vraies APIs. Une tâche simulée n'appellera jamais le point de terminaison du service. Si vous ne spécifiez pas de réponse simulée, une tâche tentera d'appeler les points de terminaison du service. De plus, Step Functions Local génère automatiquement un jeton de tâche lorsque vous simulez une tâche à l'aide du.waitForTaskToken.

Étape 1 : Spécifier les intégrations de services simulées dans un fichier de configuration fictif

Vous pouvez tester le AWS SDK Step Functions et les intégrations de services optimisées à l'aide de Step Functions Local. L'image suivante montre la machine à états définie dans l'onglet Définition de la machine à états :

Pour ce faire, vous devez créer un fichier de configuration fictif contenant les sections définies dansStructure de fichier de configuration fictive.

Étape 2 : Fournir le fichier de configuration fictif à Step Functions Local

Vous pouvez fournir le fichier de configuration fictif à Step Functions Local de l'une des manières suivantes :

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

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

Étape 3 : Exécuter des tests d'intégration de services simulés

Après avoir créé et fourni un fichier de configuration fictif à Step Functions Local, exécutez la machine d'état configurée dans le fichier de configuration fictif à l'aide d'intégrations de services simulées. Vérifiez ensuite les résultats de l'exécution à l'aide d'une action d'API.

Fichier de configuration pour les intégrations de services simulées dans Step Functions

Pour utiliser des intégrations de services simulées, vous devez d'abord créer un fichier de configuration fictif nommé MockConfigFile.json contenant vos configurations fictives. Fournissez ensuite à Step Functions Local le fichier de configuration fictif. Ce fichier de configuration définit les cas de test, qui contiennent des états fictifs utilisant des réponses d'intégration de services simulées. La section suivante contient des informations sur la structure de la configuration fictive qui inclut les états fictifs et les réponses simulées :

Structure de fichier de configuration fictive

Une configuration fictive est un objet JSON contenant les champs de niveau supérieur suivants :

Voici un exemple de fichier de configuration fictif qui inclut une StateMachine définition etMockedResponse.

{
  "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!"
          }
        }
      }
    }
  }
}

Référence de champ de configuration fictive

Les sections suivantes expliquent les champs d'objet de niveau supérieur que vous devez définir dans votre configuration fictive.

StateMachines

L'StateMachinesobjet définit les machines à états qui utiliseront des intégrations de services simulées. La configuration de chaque machine à états est représentée par un champ de niveau supérieur deStateMachines. Le nom du champ est le nom de la machine à états et la valeur est un objet contenant un seul champ nomméTestCases, dont les champs représentent des cas de test de cette machine à états.

La syntaxe suivante montre une machine à états avec deux scénarios de test :

"MyStateMachine": {
  "TestCases": {
    "HappyPath": {
      ...
    },
    "SadPath": {
      ...
    }
  }

TestCases

Les champs de TestCases représentent des cas de test individuels pour la machine à états. Le nom de chaque cas de test doit être unique par machine d'état et la valeur de chaque cas de test est un objet spécifiant une réponse simulée à utiliser pour les états de tâche dans la machine d'état.

L'exemple de a suivant TestCase lie deux Task états à deux MockedResponses :

"HappyPath": {
  "SomeTaskState": "SomeMockedResponse",
  "AnotherTaskState": "AnotherMockedResponse"
}

MockedResponses

MockedResponsesest un objet contenant plusieurs objets de réponse simulés avec des noms de champs uniques. Un objet de réponse simulé définit le résultat réussi ou la sortie d'erreur pour chaque appel d'un état de tâche simulé. Vous spécifiez le numéro d'appel à l'aide de chaînes entières individuelles, telles que « 0 », « 1 », « 2 » et « 3 » ou d'une plage inclusive d'entiers, telle que « 0-1 », « 2-3 ».

Lorsque vous simulez une tâche, vous devez spécifier une réponse simulée pour chaque appel. Une réponse doit contenir un seul champ nommé Return ou Throw dont la valeur est le résultat ou la sortie d'erreur de l'invocation de tâche simulée. Si vous ne spécifiez pas de réponse simulée, l'exécution de la machine à états échouera.

Voici un exemple de MockedResponse with Throw et d'Returnobjets. Dans cet exemple, les trois premières fois que la machine d'état est exécutée, la réponse spécifiée dans "0-2" est renvoyée, et la quatrième fois que la machine d'état s'exécute, la réponse spécifiée dans "3" est renvoyée.

"SomeMockedResponse": {
  "0-2": {
    "Throw": {
      ...
    }
  },
  "3": {
    "Return": {
      ...
    }
  }
}

Return

Returnest représenté sous la forme d'un champ d'MockedResponseobjets. Il indique le résultat positif d'un état de tâche simulé.

Voici un exemple d'Returnobjet contenant une réponse simulée pour l'appel d'une Invokefonction Lambda :

"Return": {
  "StatusCode": 200,
  "Payload": {
    "StatusCode": 200,
    "body": "Hello from Lambda!"
  }
}

Jeter

Throwest représenté sous la forme d'un champ d'MockedResponseobjets. Il indique le résultat d'erreur d'une tâche ayant échoué. La valeur de Throw doit être un objet contenant des Cause champs Error et avec des valeurs de chaîne. En outre, la valeur de chaîne que vous spécifiez dans le Error champ MockConfigFile.json doit correspondre aux erreurs gérées dans les Catch sections Retry et de votre machine à états.

Voici un exemple d'Throwobjet contenant une réponse simulée pour l'appel d'une Invokefonction Lambda :

"Throw": {
  "Error": "Lambda.TimeoutException",
  "Cause": "Lambda timed out."
}