Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Uso de integraciones de servicios simuladas para realizar pruebas en Step Functions Local
**Step Functions Local no es compatible**
Step Functions Local **no** proporciona paridad de características y **no es compatible**.
Podría considerar soluciones de terceros que emulen Step Functions con fines de prueba.
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.
**nota**
Si no especificas respuestas de integración de servicios simuladas en el archivo de configuración simulado, Step Functions Local invocará la integración de AWS servicios mediante el punto final que configuraste al configurar Step Functions Local. Para obtener información sobre la configuración de puntos de conexión para Step Functions Local, consulte [Configurar opciones de configuración para Step Functions Local](sfn-local.md#sfn-local-config-options).
En este tema se utilizan varios conceptos que se definen en la siguiente lista:
+ Integraciones de servicios simuladas: se refiere a los estados Task configurados para utilizar respuestas simuladas en lugar de realizar llamadas de servicio reales.
+ Respuestas simuladas: se refiere a datos simulados que los estados Task pueden configurar para usar.
+ Casos de prueba: se refieren a las ejecuciones de máquinas de estado configuradas para utilizar integraciones de servicios simuladas.
+ Archivo de configuración simulado: se refiere al archivo de configuración simulado que contiene JSON, que define las integraciones de servicios simuladas, las respuestas simuladas y los casos de prueba.
## 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:
![\[Ejemplo de integración de servicios simulada.\]](http://docs.aws.amazon.com/es_es/step-functions/latest/dg/images/msi-graph.png)
Para ello, debe crear un archivo de configuración simulado que contenga las secciones definidas en [Estructura del archivo de configuración del archivo](#mock-cfg-struct).
1. Cree un archivo con el nombre `MockConfigFile.json` para configurar las pruebas con integraciones de servicios simuladas.
En el siguiente ejemplo se muestra un archivo de configuración simulado que hace referencia a una máquina de estado con dos estados definidos denominados `LambdaState` y `SQSState`
------
#### [ Mock configuration file example ]
A continuación se muestra un ejemplo de un archivo de configuración simulado que muestra cómo simular respuestas al [invocar una función de Lambda](connect-lambda.md) y [enviar un mensaje a Amazon SQS](connect-sqs.md). En este ejemplo, la máquina de estado [`LambdaSQSIntegration`](#mock-cfg-sm-sect) contiene tres casos de prueba denominados `HappyPath`, `RetryPath` y `HybridPath` que simulan los estados `Task` denominados `LambdaState` y `SQSState`. Estos estados utilizan las respuestas de servicio simuladas `MockedLambdaSuccess`, `MockedSQSSuccess` y `MockedLambdaRetry`. Estas respuestas de servicio simuladas se definen en la sección `MockedResponses` del archivo.
```
{
"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 ]
A continuación se muestra un ejemplo de una definición de máquina de estado denominada `LambdaSQSIntegration`, que define dos estados de tareas de integración de servicios denominados `LambdaState` y `SQSState`. `LambdaState` contiene una política de reintentos basada en `States.ALL`.
```
{
"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/account-id/myQueue",
"MessageBody.$":"$"
},
"End": true
}
}
}
```
------
Puede ejecutar la definición de la máquina de estado `LambdaSQSIntegration` a la que se hace referencia en el archivo de configuración simulado mediante uno de los siguientes casos de prueba:
+ `HappyPath`: esta prueba simula la salida de `LambdaState` y `SQSState` mediante `MockedLambdaSuccess` y `MockedSQSSuccess`, respectivamente.
+ El `LambdaState` devolverá los siguientes valores:
```
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
```
+ El `SQSState` devolverá los siguientes valores:
```
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
```
+ `RetryPath`: esta prueba simula la salida de `LambdaState` y `SQSState` mediante `MockedLambdaRetry` y `MockedSQSSuccess`, respectivamente. Además, `LambdaState` está configurada para realizar cuatro reintentos. Las respuestas simuladas para estos intentos se definen e indexan en el estado `MockedLambdaRetry`.
+ El intento inicial finaliza con un error en la tarea que contiene un mensaje de causa y error, como se muestra en el siguiente ejemplo:
```
"0":{
"Throw": {
"Error": "Lambda.ResourceNotReadyException",
"Cause": "Lambda resource is not ready."
}
}
```
+ El primer y el segundo intento finalizan con un error en la tarea que contiene un mensaje de causa y error, como se muestra en el siguiente ejemplo:
```
"1-2":{
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
}
```
+ El tercer intento finaliza con una tarea exitosa que contiene el resultado de estado de la sección Carga en la respuesta de Lambda simulada.
```
"3":{
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
}
```
**nota**
En el caso de los estados con una política de reintentos, Step Functions Local agotará los reintentos establecidos en la política hasta que reciba una respuesta correcta. Esto significa que debe denotar simulaciones para los reintentos con números de intentos consecutivos y debe cubrir todos los reintentos antes de obtener una respuesta correcta.
Si no especifica una respuesta simulada para un reintento específico (por ejemplo, si reintenta «3»), la ejecución de la máquina de estado generará un error.
+ `HybridPath`: esta prueba simula la salida de `LambdaState`. Después de que `LambdaState` se ejecute correctamente y reciba datos simulados como respuesta, `SQSState` realiza una llamada de servicio real al recurso especificado en producción.
Para obtener información sobre cómo iniciar las ejecuciones de pruebas con integraciones de servicios simuladas, consulte [Paso 3: Ejecutar pruebas de integración de servicios simuladas](#run-mocked-serv-integ-tests).
1. Asegúrese de que la estructura de las respuestas simuladas se ajuste a la estructura de las respuestas de servicio reales que recibe cuando realiza llamadas de servicio integradas. Para obtener información sobre los requisitos estructurales de las respuestas simuladas, consulte [Configuración de integraciones de servicios simuladas](#mock-resp-struct-req).
En el archivo de configuración simulada del ejemplo anterior, las respuestas simuladas definidas en `MockedLambdaSuccess` y `MockedLambdaRetry` se ajustan a la estructura de las respuestas reales que se devuelven al llamar a `HelloFromLambda`.
**importante**
Las respuestas del servicio de AWS pueden variar entre los distintos servicios. Step Functions Local no valida si las estructuras de respuesta simuladas se ajustan a las estructuras de respuesta del servicio reales. Debe asegurarse de que sus respuestas simuladas se ajusten a las respuestas reales antes de realizar la prueba. Para revisar la estructura de las respuestas de servicios, puede realizar las llamadas de servicio reales mediante Step Functions o consultar la documentación de dichos servicios.
## 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 ]
**nota**
Si utiliza la versión Docker de Step Functions Local, puede proporcionar el archivo de configuración simulado utilizando únicamente una variable de entorno. Además, debe montar el archivo de configuración simulado en el contenedor de Step Functions Local en el arranque inicial del servidor.
Monte el archivo de configuración simulado en cualquier directorio del contenedor de Step Functions Local. A continuación, defina una variable de entorno denominada `SFN_MOCK_CONFIG` que contenga la ruta al archivo de configuración simulado del contenedor. Este método permite que el archivo de configuración simulado reciba cualquier nombre siempre que la variable de entorno contenga la ruta y el nombre del archivo.
El siguiente comando muestra el formato para iniciar la imagen de Docker.
```
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
```
En el siguiente ejemplo se utiliza el comando para iniciar la imagen de Docker.
```
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 ]
Use una de las siguientes formas para proporcionar el archivo de configuración simulado a Step Functions Local:
+ Coloque el archivo de configuración simulado en el mismo directorio que `Step FunctionsLocal.jar`. Al usar este método, debe asignar un nombre al archivo de configuración simulado `MockConfigFile.json`.
+ En la sesión en la que se ejecuta Step Functions Local, defina una variable de entorno denominada `SFN_MOCK_CONFIG`, con la ruta completa del archivo de configuración simulado. Este método permite que el archivo de configuración simulado reciba cualquier nombre siempre que la variable de entorno contenga la ruta y el nombre del archivo. En el siguiente ejemplo, la variable `SFN_MOCK_CONFIG` se establece para que apunte a un archivo de configuración simulado denominado `EnvSpecifiedMockConfig.json`, ubicado en el directorio `/home/workspace`.
```
export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
```
**nota**
Si no se proporciona la variable de entorno `SFN_MOCK_CONFIG` a Step Functions Local, de forma predeterminada, intentará leer un archivo de configuración simulado denominado `MockConfigFile.json` en el directorio desde el que se inició Step Functions Local.
Si coloca el archivo de configuración simulado en el mismo directorio que `Step FunctionsLocal.jar` y establece la variable de entorno `SFN_MOCK_CONFIG`, Step Functions Local leerá el archivo especificado por la variable de entorno.
------
## 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.
1. Cree una máquina de estado basada en la definición mencionada anteriormente en el [archivo de configuración simulado](#create-mock-config-file).
```
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"
```
1. Ejecute la máquina de estado mediante integraciones de servicios simuladas.
Para usar el archivo de configuración simulado, realice una llamada a la API `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` en una máquina de estado configurada en el archivo de configuración simulado. Para ello, añada el sufijo ,`#test_name`, al ARN de la máquina de estado utilizado por `StartExecution`. `test_name` es un caso de prueba, que se configura para la máquina de estado en el mismo archivo de configuración simulado.
El siguiente comando es un ejemplo que utiliza la máquina de estado `LambdaSQSIntegration` y la configuración simulada. En este ejemplo, la máquina de estado `LambdaSQSIntegration` se ejecuta mediante la prueba `HappyPath` definida en [Paso 1: Especificar las integraciones de servicios simuladas en un archivo de configuración simulado](#create-mock-config-file). La prueba `HappyPath` contiene la configuración de la ejecución para gestionar las llamadas de integración de servicios simuladas que los estados `LambdaState` y `SQSState` realizan mediante las respuestas de servicio simuladas `MockedLambdaSuccess` y `MockedSQSSuccess`.
```
aws stepfunctions start-execution \
--endpoint http://localhost:8083 \
--name executionWithHappyPathMockedServices \
--state-machine arn:aws:states:region:account-id:stateMachine:LambdaSQSIntegration#HappyPath
```
1. Vea el estado de la respuesta de ejecución de la máquina.
La respuesta a una llamada a `StartExecution` mediante una prueba de integración de servicios simulada es la misma que la respuesta a una llamada a `StartExecution` normal, que devuelve el ARN de ejecución y la fecha de inicio.
A continuación se muestra un ejemplo de respuesta a una llamada `StartExecution` mediante la prueba de integración de servicios simulada:
```
{
"startDate":"2022-01-28T15:03:16.981000-05:00",
"executionArn":"arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```
1. Compruebe los resultados de la ejecución realizando una llamada a la API `[ListExecutions](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListExecutions.html)`, `[DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html)` o `[GetExecutionHistory](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetExecutionHistory.html)`
```
aws stepfunctions get-execution-history \
--endpoint http://localhost:8083 \
--execution-arn arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices
```
En el siguiente ejemplo se muestran partes de una respuesta a una llamada a `GetExecutionHistory` mediante el ARN de ejecución de la respuesta de ejemplo que se muestra en el paso 2. En este ejemplo, la salida de `LambdaState` y `SQSState` son los datos simulados definidos en `MockedLambdaSuccess` y `MockedSQSSuccess` en el [archivo de configuración simulado](#create-mock-config-file). Además, los datos simulados se utilizan de la misma manera que los datos devueltos al realizar llamadas de integración de servicios reales. Además, en este ejemplo, la salida de `LambdaState` se transfiere a `SQSState` como entrada.
```
{
"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
}
}
},
...
]
}
```
## Archivo de configuración para integraciones de servicios simulados en Step Functions
**Step Functions Local no es compatible**
Step Functions Local **no** proporciona paridad de características y **no es compatible**.
Podría considerar soluciones de terceros que emulen Step Functions con fines de prueba.
Como alternativa a Step Functions Local, puedes usar la TestState API para realizar pruebas unitarias de la lógica de tu máquina de estados antes de implementarla en tu AWS cuenta. Para obtener más información, consulta [Probar máquinas de estado con la TestState API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
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:
+ `StateMachines`: los campos de este objeto representan máquinas de estado configuradas para utilizar integraciones de servicios simuladas.
+ `MockedResponse`: los campos de este objeto representan respuestas simuladas para las llamadas de integración de servicios.
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](#mock-cfg-sm-sect)
+ [MockedResponses](#mock-cfg-mckd-resp-sect)
##### 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": {
...
}
}
}
```
**nota**
Si utiliza un estado `Map` y quiere garantizar respuestas predecibles para el estado `Map`, defina el valor de `maxConcurrency` en 1. Si establece un valor superior a 1, Step Functions Local ejecutará varias iteraciones simultáneamente, lo que provocará que el orden general de ejecución de los estados de las iteraciones sea impredecible. Además, esto puede provocar que Step Functions Local utilice diferentes respuestas simuladas para los estados de iteración de una ejecución a la siguiente.
##### 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 [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) 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](concepts-error-handling.md) 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 [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) en una función de Lambda:
```
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
```