Uso de integraciones de servicios simuladas para realizar pruebas en Step Functions Local

En Step Functions Local, puede probar las rutas de ejecución de sus máquinas de estado sin llamar realmente a los servicios integrados mediante integraciones de servicios simuladas. Para configurar sus máquinas de estado para que utilicen integraciones de servicios simuladas, cree un archivo de configuración simulado. En este archivo, defina la salida deseada de sus integraciones de servicios como respuestas simuladas y las ejecuciones que utilizan sus respuestas simuladas para simular una ruta de ejecución como casos de prueba.

Al proporcionar el archivo de configuración simulado a Step Functions Local, puede probar las llamadas de integración de servicios ejecutando máquinas de estado que utilizan las respuestas simuladas especificadas en los casos de prueba en lugar de realizar llamadas de integración de servicios reales.

En este tema se utilizan varios conceptos que se definen en la siguiente lista:

Configuración de integraciones de servicios simuladas

Puede simular cualquier integración de servicios mediante Step Functions Local. Sin embargo, Step Functions Local no exige que los simulacros sean iguales a los reales APIs. Una tarea simulada nunca llamará al punto de conexión del servicio. Si no especifica una respuesta simulada, una tarea intentará llamar a los puntos de conexión del servicio. Además, Step Functions Local generará automáticamente un token de tarea cuando simule una tarea con .waitForTaskToken.

Paso 1: Especificar las integraciones de servicios simuladas en un archivo de configuración simulado

Puede probar el AWS SDK de Step Functions y las integraciones de servicios optimizadas mediante Step Functions Local. En la siguiente imagen se muestra la máquina de estado definida en la pestaña Definición de máquina de estado:

Para ello, debe crear un archivo de configuración simulado que contenga las secciones definidas en Estructura del archivo de configuración del archivo.

Paso 2: Proporcionar el archivo de configuración simulado a Step Functions Local

Puede proporcionar el archivo de configuración simulado a Step Functions Local de una de las siguientes maneras:

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

Paso 3: Ejecutar pruebas de integración de servicios simuladas

Después de crear y proporcionar un archivo de configuración simulado a Step Functions Local, ejecute la máquina de estado configurada en el archivo de configuración simulado mediante integraciones de servicios simuladas. A continuación, compruebe los resultados de la ejecución mediante una acción de API.

Archivo de configuración para integraciones de servicios simulados en Step Functions

Para usar integraciones de servicios simuladas, primero debe crear un archivo de configuración simulado denominado MockConfigFile.json que contenga las configuraciones simuladas. A continuación, proporcione a Step Functions Local el archivo de configuración simulado. Este archivo de configuración define los casos de prueba, que contienen estados simulados que utilizan respuestas de integración de servicios simuladas. La siguiente sección contiene información sobre la estructura de la configuración simulada, que incluye los estados simulados y las respuestas simuladas:

Estructura del archivo de configuración del archivo

Una configuración simulada es un objeto JSON que contiene los siguientes campos de nivel superior:

A continuación se muestra un ejemplo de un archivo de configuración simulado que incluye una definición StateMachine y MockedResponse.

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

Referencia de campo de configuración simulada

En las siguientes secciones se explican los campos de objetos de nivel superior que debe definir en la configuración simulada.

StateMachines

El objeto StateMachines define qué máquinas de estado utilizarán integraciones de servicios simuladas. La configuración de cada máquina de estado se representa como un campo de nivel superior de StateMachines. El nombre del campo es el nombre de la máquina de estado y el valor es un objeto que contiene un único campo denominado TestCases, cuyos campos representan casos de prueba de esa máquina de estado.

La siguiente sintaxis muestra una máquina de estado con dos casos de prueba:

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

TestCases

Los campos de TestCases representan casos de prueba individuales para la máquina de estado. El nombre de cada caso de prueba debe ser único para cada máquina de estado y el valor de cada caso de prueba es un objeto que especifica una respuesta simulada para utilizarla en los estados Task de la máquina de estado.

El siguiente ejemplo de TestCase vincula dos estados Task a dos MockedResponses:

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

MockedResponses

MockedResponses es un objeto que contiene varios objetos de respuesta simulados con nombres de campo únicos. Un objeto de respuesta simulado define el resultado correcto o la salida con error de cada invocación de un estado Task simulado. El número de invocación se especifica mediante cadenas de números enteros individuales, como «0», «1», «2» y «3», o un rango inclusivo de números enteros, como «0-1», «2-3».

Cuando se simula una tarea, se debe especificar una respuesta simulada para cada invocación. La respuesta debe contener un único campo denominado Return o Throw cuyo valor sea el resultado o error de la invocación de la tarea simulada. Si no especifica una respuesta simulada, la ejecución de la máquina de estado generará un error.

A continuación se muestra un ejemplo de una MockedResponse con Throw y Return objetos. En este ejemplo, las tres primeras veces que se ejecuta la máquina de estado, se devuelve la respuesta especificada en "0-2", y la cuarta vez que se ejecuta la máquina de estado, se devuelve la respuesta especificada en "3".

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

Return

Return se representa como un campo de los objetos MockedResponse. Especifica el resultado correcto de un estado Task simulado.

A continuación se muestra un ejemplo de un objeto Return que contiene una respuesta simulada para llamar a Invoke en una función de Lambda:

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

Throw

Throw se representa como un campo de los objetos MockedResponse. Especifica la salida de error de una tarea fallida. El valor de Throw debe ser un objeto que contenga campos Error y Cause con valores de cadena. Además, el valor de cadena que especifique en el campo Error en MockConfigFile.json debe coincidir con los errores gestionados en las secciones Retry y Catch de su máquina de estado.

A continuación se muestra un ejemplo de un objeto Throw que contiene una respuesta simulada para llamar a Invoke en una función de Lambda:

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