Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo di integrazioni di servizi simulate per i test in Step Functions Local
**Step Functions Local non è supportato**
Step Functions Local **non** fornisce parità di funzionalità e **non** è supportato.
Potresti prendere in considerazione soluzioni di terze parti che emulano Step Functions a scopo di test.
In Step Functions Local, puoi testare i percorsi di esecuzione delle tue macchine a stati senza chiamare effettivamente servizi integrati utilizzando integrazioni di servizi simulate. Per configurare le macchine a stati per utilizzare integrazioni di servizi simulate, create un file di configurazione fittizio. In questo file, definisci l'output desiderato delle integrazioni di servizio come risposte simulate e le esecuzioni che utilizzano le risposte simulate per simulare un percorso di esecuzione come casi di test.
Fornendo il file di configurazione fittizio a Step Functions Local, è possibile testare le chiamate di integrazione dei servizi eseguendo macchine a stati che utilizzano le risposte simulate specificate nei casi di test invece di effettuare chiamate di integrazione del servizio effettive.
**Nota**
Se non specifichi risposte simulate di integrazione del servizio nel file di configurazione fittizio, Step Functions Local invocherà l'integrazione del AWS servizio utilizzando l'endpoint configurato durante la configurazione di Step Functions Local. Per informazioni sulla configurazione degli endpoint per Step Functions Local, vedere. [Impostazione delle opzioni di configurazione per Step Functions Local](sfn-local.md#sfn-local-config-options)
Questo argomento utilizza diversi concetti definiti nell'elenco seguente:
+ Integrazioni di servizi simulati: si riferisce agli stati delle attività configurati per utilizzare risposte simulate anziché eseguire chiamate di servizio effettive.
+ Risposte simulate: si riferisce a dati fittizi per i quali gli stati di Task possono essere configurati per l'utilizzo.
+ Casi di test: si riferisce alle esecuzioni di macchine a stati configurate per utilizzare integrazioni di servizi simulate.
+ File di configurazione fittizio: si riferisce al file di configurazione fittizio che contiene JSON, che definisce integrazioni di servizi simulate, risposte simulate e casi di test.
## Configurazione di integrazioni di servizi simulate
Puoi simulare qualsiasi integrazione di servizi utilizzando Step Functions Local. Tuttavia, Step Functions Local non impone che i mock siano uguali a quelli reali. APIs Un Task simulato non chiamerà mai l'endpoint del servizio. Se non si specifica una risposta simulata, un Task tenterà di chiamare gli endpoint del servizio. Inoltre, Step Functions Local genererà automaticamente un token di attività quando simuli un Task utilizzando il`.waitForTaskToken`.
## Passo 1: Specificare le integrazioni di servizi simulati in un file di configurazione fittizio
Puoi testare Step Functions AWS SDK e integrazioni di servizi ottimizzate utilizzando Step Functions Local. L'immagine seguente mostra la macchina a stati definita nella scheda Definizione della macchina a stati:
A tale scopo, è necessario creare un file di configurazione fittizio contenente le sezioni definite in. [Struttura fittizia del file di configurazione](#mock-cfg-struct)
1. Crea un file denominato `MockConfigFile.json` per configurare i test con integrazioni di servizi simulate.
L'esempio seguente mostra un file di configurazione fittizio che fa riferimento a una macchina a stati con due stati definiti denominati and. `LambdaState` `SQSState`
------
#### [ Mock configuration file example ]
Di seguito è riportato un esempio di file di configurazione fittizio che dimostra come simulare le risposte richiamando una funzione [Lambda e inviando un](connect-lambda.md) [messaggio](connect-sqs.md) ad Amazon SQS. In questo esempio, la macchina a [`LambdaSQSIntegration`](#mock-cfg-sm-sect)stati contiene tre casi di test denominati`HappyPath`,`RetryPath`, e `HybridPath` che simulano gli stati denominati and. `Task` `LambdaState` `SQSState` Questi stati utilizzano le risposte di `MockedLambdaSuccess` servizio `MockedSQSSuccess` simulate e `MockedLambdaRetry` simulate. Queste risposte di servizio simulate sono definite nella `MockedResponses` sezione del file.
```
{
"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 ]
Di seguito è riportato un esempio di definizione di macchina a stati denominata`LambdaSQSIntegration`, che definisce due stati delle attività di integrazione dei servizi denominati `LambdaState` and. `SQSState` `LambdaState`contiene una politica di ripetizione dei tentativi basata su. `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
}
}
}
```
------
È possibile eseguire la definizione della macchina a `LambdaSQSIntegration` stati a cui si fa riferimento nel file di configurazione fittizio utilizzando uno dei seguenti casi di test:
+ `HappyPath`- Questo test simula rispettivamente l'output e l'`SQSState`utilizzo `MockedLambdaSuccess` di `LambdaState` e. `MockedSQSSuccess`
+ `LambdaState`Restituirà il seguente valore:
```
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
```
+ `SQSState`Restituirà il seguente valore:
```
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
```
+ `RetryPath`- Questo test simula `MockedSQSSuccess` rispettivamente l'output `LambdaState` e `SQSState` l'utilizzo di `MockedLambdaRetry` e. Inoltre, `LambdaState` è configurato per eseguire quattro tentativi di nuovo tentativo. Le risposte simulate per questi tentativi sono definite e indicizzate nello stato. `MockedLambdaRetry`
+ Il tentativo iniziale termina con un'operazione non riuscita contenente un messaggio di causa e di errore, come illustrato nell'esempio seguente:
```
"0":{
"Throw": {
"Error": "Lambda.ResourceNotReadyException",
"Cause": "Lambda resource is not ready."
}
}
```
+ Il primo e il secondo tentativo terminano con un errore dell'operazione contenente un messaggio di causa e di errore, come illustrato nell'esempio seguente:
```
"1-2":{
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
}
```
+ Il terzo tentativo termina con un'operazione riuscita contenente il risultato dello stato della sezione Payload nella risposta Lambda simulata.
```
"3":{
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
}
```
**Nota**
Per gli stati con una politica di nuovi tentativi, Step Functions Local esaurirà i tentativi di riprova impostati nella politica fino a quando non riceverà una risposta positiva. Ciò significa che, per i tentativi ripetuti, è necessario indicare un numero di tentativi consecutivi e includere tutti i tentativi ripetuti prima di restituire una risposta riuscita.
Se non si specifica una risposta simulata per un tentativo specifico, ad esempio, riprova «3", l'esecuzione della macchina a stati avrà esito negativo.
+ `HybridPath`- Questo test simula l'output di. `LambdaState` Dopo aver `LambdaState` eseguito correttamente e ricevuto dati simulati come risposta, `SQSState` esegue una chiamata di servizio effettiva alla risorsa specificata in produzione.
Per informazioni su come avviare esecuzioni di test con integrazioni di servizi simulate, consulta. [Fase 3: Eseguire i test di integrazione dei servizi simulati](#run-mocked-serv-integ-tests)
1. Assicurati che la struttura delle risposte simulate sia conforme alla struttura delle risposte di servizio effettive che ricevi quando effettui chiamate di servizio integrate. Per informazioni sui requisiti strutturali per le risposte simulate, vedere. [Configurazione di integrazioni di servizi simulate](#mock-resp-struct-req)
Nell'esempio precedente, il file di configurazione fittizio, le risposte simulate sono definite `MockedLambdaSuccess` e sono `MockedLambdaRetry` conformi alla struttura delle risposte effettive restituite dalla chiamata. `HelloFromLambda`
**Importante**
AWS le risposte al servizio possono variare nella struttura tra i diversi servizi. Step Functions Local non verifica se le strutture di risposta simulate sono conformi alle strutture di risposta del servizio effettive. È necessario assicurarsi che le risposte simulate siano conformi alle risposte effettive prima del test. Per esaminare la struttura delle risposte di servizio, è possibile eseguire le chiamate di servizio effettive utilizzando Step Functions o visualizzare la documentazione relativa a tali servizi.
## Passaggio 2: fornire il file di configurazione fittizio a Step Functions Local
È possibile fornire il file di configurazione fittizio a Step Functions Local in uno dei seguenti modi:
------
#### [ Docker ]
**Nota**
Se utilizzi la versione Docker di Step Functions Local, puoi fornire il file di configurazione fittizio utilizzando solo una variabile di ambiente. Inoltre, è necessario montare il file di configurazione fittizio nel contenitore Step Functions Local all'avvio iniziale del server.
Monta il file di configurazione fittizio su qualsiasi directory all'interno del contenitore Step Functions Local. Quindi, imposta una variabile di ambiente denominata `SFN_MOCK_CONFIG` che contiene il percorso del file di configurazione fittizio nel contenitore. Questo metodo consente di assegnare qualsiasi nome al file di configurazione fittizio purché la variabile di ambiente contenga il percorso e il nome del file.
Il comando seguente mostra il formato per avviare l'immagine 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
```
L'esempio seguente utilizza il comando per avviare l'immagine 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 ]
Utilizzate uno dei seguenti modi per fornire il file di configurazione fittizio a Step Functions Local:
+ Posiziona il file di configurazione fittizio nella stessa directory di. `Step FunctionsLocal.jar` Quando si utilizza questo metodo, è necessario assegnare un nome al file di configurazione fittizio. `MockConfigFile.json`
+ Nella sessione che esegue Step Functions Local, imposta una variabile di ambiente denominata`SFN_MOCK_CONFIG`, sul percorso completo del file di configurazione fittizio. Questo metodo consente di denominare il file di configurazione fittizio con qualsiasi nome purché la variabile di ambiente contenga il percorso e il nome del file. Nell'esempio seguente, la `SFN_MOCK_CONFIG` variabile è impostata in modo che punti a un file di configurazione fittizio denominato`EnvSpecifiedMockConfig.json`, che si trova nella `/home/workspace` directory.
```
export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
```
**Nota**
Se non si fornisce la variabile di ambiente `SFN_MOCK_CONFIG` a Step Functions Local, per impostazione predefinita, tenterà di leggere un file di configurazione fittizio denominato `MockConfigFile.json` nella directory da cui è stato avviato Step Functions Local.
Se si posiziona il file di configurazione fittizio nella stessa directory `Step FunctionsLocal.jar` e si imposta la variabile di ambiente`SFN_MOCK_CONFIG`, Step Functions Local leggerà il file specificato dalla variabile di ambiente.
------
## Fase 3: Eseguire i test di integrazione dei servizi simulati
Dopo aver creato e fornito un file di configurazione fittizio a Step Functions Local, esegui la macchina a stati configurata nel file di configurazione fittizio utilizzando integrazioni di servizi fittizi. Quindi controlla i risultati dell'esecuzione utilizzando un'azione API.
1. Crea una macchina a stati basata sulla definizione menzionata in precedenza nel [file di configurazione fittizio](#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. Esegui la macchina a stati utilizzando integrazioni di servizi simulate.
Per utilizzare il file di configurazione fittizio, effettua una chiamata `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API su una macchina a stati configurata nel file di configurazione fittizio. A tale scopo, aggiungi il suffisso,`#{{test_name}}`, all'ARN della macchina a stati utilizzata da. `StartExecution` `{{test_name}}`è un test case, configurato per la macchina a stati nello stesso file di configurazione fittizio.
Il comando seguente è un esempio che utilizza la macchina a `LambdaSQSIntegration` stati e la configurazione fittizia. In questo esempio, la macchina a `LambdaSQSIntegration` stati viene eseguita utilizzando il `HappyPath` test definito in[Passo 1: Specificare le integrazioni di servizi simulati in un file di configurazione fittizio](#create-mock-config-file). Il `HappyPath` test contiene la configurazione per l'esecuzione per gestire le chiamate di integrazione di servizi fittizi effettuate `LambdaState` e `SQSState` dagli stati utilizzando le risposte del `MockedLambdaSuccess` servizio `MockedSQSSuccess` simulate.
```
aws stepfunctions start-execution \
--endpoint http://localhost:8083 \
--name executionWithHappyPathMockedServices \
--state-machine arn:aws:states:{{region}}:{{account-id}}:stateMachine:LambdaSQSIntegration#HappyPath
```
1. Visualizza la risposta di esecuzione della macchina a stati.
La risposta alla chiamata `StartExecution` utilizzando un test di integrazione del servizio simulato è la stessa della risposta alla chiamata `StartExecution` normale, che restituisce l'ARN di esecuzione e la data di inizio.
Di seguito è riportato un esempio di risposta alla chiamata `StartExecution` utilizzando il test di integrazione del servizio simulato:
```
{
"startDate":"2022-01-28T15:03:16.981000-05:00",
"executionArn":"arn:aws:states:{{region}}:{{account-id}}:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```
1. Controlla i risultati dell'esecuzione effettuando una chiamata `[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)` API.
```
aws stepfunctions get-execution-history \
--endpoint http://localhost:8083 \
--execution-arn arn:aws:states:{{region}}:{{account-id}}:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices
```
L'esempio seguente mostra parti di una risposta alla chiamata `GetExecutionHistory` utilizzando l'ARN di esecuzione dalla risposta di esempio mostrata nel passaggio 2. In questo esempio, l'output di `LambdaState` e `SQSState` è costituito dai dati fittizi definiti nel `MockedLambdaSuccess` e `MockedSQSSuccess` nel file di configurazione [fittizio](#create-mock-config-file). Inoltre, i dati simulati vengono utilizzati nello stesso modo in cui verrebbero utilizzati i dati restituiti eseguendo chiamate di integrazione dei servizi effettive. Inoltre, in questo esempio, l'output da `LambdaState` viene passato `SQSState` come input.
```
{
"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
}
}
},
...
]
}
```
## File di configurazione per integrazioni di servizi simulate in Step Functions
**Step Functions Local non è supportato**
Step Functions Local **non** fornisce parità di funzionalità e **non** è supportato.
Potresti prendere in considerazione soluzioni di terze parti che emulano Step Functions a scopo di test.
In alternativa a Step Functions Local, puoi utilizzare l' TestState API per testare unitariamente la logica della tua macchina a stati prima di distribuirla AWS sul tuo account. Per ulteriori informazioni, consulta [Testare le macchine a stati con l' TestState API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Per utilizzare integrazioni di servizi fittizi, devi prima creare un file di configurazione fittizio denominato `MockConfigFile.json` contenente le tue configurazioni fittizie. Quindi fornisci a Step Functions Local il file di configurazione fittizio. Questo file di configurazione definisce i casi di test, che contengono stati fittizi che utilizzano risposte simulate di integrazione dei servizi. La sezione seguente contiene informazioni sulla struttura della configurazione fittizia che include gli stati fittizi e le risposte simulate:
### Struttura fittizia del file di configurazione
Una configurazione fittizia è un oggetto JSON contenente i seguenti campi di primo livello:
+ `StateMachines`- I campi di questo oggetto rappresentano macchine a stati configurate per utilizzare integrazioni di servizi simulate.
+ `MockedResponse`- I campi di questo oggetto rappresentano risposte simulate per le chiamate di integrazione dei servizi.
Di seguito è riportato un esempio di un file di configurazione fittizio che include una `StateMachine` definizione e. `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!"
}
}
}
}
}
}
```
#### Riferimento al campo di configurazione fittizio
Le sezioni seguenti spiegano i campi oggetto di primo livello che è necessario definire nella configurazione fittizia.
+ [StateMachines](#mock-cfg-sm-sect)
+ [MockedResponses](#mock-cfg-mckd-resp-sect)
##### StateMachines
L'`StateMachines`oggetto definisce quali macchine a stati utilizzeranno integrazioni di servizi simulate. La configurazione per ogni macchina a stati è rappresentata come un campo di primo livello di. `StateMachines` Il nome del campo è il nome della macchina a stati e il valore è un oggetto contenente un singolo campo denominato`TestCases`, i cui campi rappresentano i casi di test di quella macchina a stati.
La sintassi seguente mostra una macchina a stati con due casi di test:
```
"MyStateMachine": {
"TestCases": {
"HappyPath": {
...
},
"SadPath": {
...
}
}
```
##### TestCases
I campi `TestCases` rappresentano singoli casi di test per la macchina a stati. Il nome di ogni test case deve essere univoco per macchina a stati e il valore di ogni test case è un oggetto che specifica una risposta simulata da utilizzare per gli stati Task nella macchina a stati.
L'esempio seguente `TestCase` collega due `Task` stati a due: `MockedResponses`
```
"HappyPath": {
"SomeTaskState": "SomeMockedResponse",
"AnotherTaskState": "AnotherMockedResponse"
}
```
##### MockedResponses
`MockedResponses`è un oggetto contenente più oggetti di risposta simulati con nomi di campo univoci. Un oggetto di risposta simulato definisce il risultato positivo o l'output di errore per ogni invocazione di uno stato Task simulato. È possibile specificare il numero di invocazione utilizzando singole stringhe di numeri interi, come «0", «1", «2" e «3" o un intervallo inclusivo di numeri interi, come «0-1», «2-3».
Quando si simula un Task, è necessario specificare una risposta simulata per ogni invocazione. Una risposta deve contenere un singolo campo denominato `Return` o il `Throw` cui valore è l'output del risultato o dell'errore per la chiamata simulata del Task. Se non si specifica una risposta simulata, l'esecuzione della macchina a stati avrà esito negativo.
Di seguito è riportato un esempio di `MockedResponse` con `Throw` e `Return` oggetti. In questo esempio, le prime tre volte che viene eseguita la macchina a stati, `"0-2"` viene restituita la risposta specificata in e la quarta volta che viene eseguita la macchina a stati, `"3"` viene restituita la risposta specificata in.
```
"SomeMockedResponse": {
"0-2": {
"Throw": {
...
}
},
"3": {
"Return": {
...
}
}
}
```
**Nota**
Se utilizzate uno `Map` stato e desiderate garantire risposte prevedibili per `Map` tale stato, impostate il valore su 1. `maxConcurrency` Se imposti un valore maggiore di 1, Step Functions Local eseguirà più iterazioni contemporaneamente, il che renderà imprevedibile l'ordine di esecuzione complessivo degli stati tra le iterazioni. Ciò potrebbe inoltre far sì che Step Functions Local utilizzi risposte simulate diverse per gli stati di iterazione da un'esecuzione all'altra.
##### Return
`Return`è rappresentato come un campo degli oggetti. `MockedResponse` Specifica il risultato positivo di uno stato Task simulato.
Di seguito è riportato un esempio di `Return` oggetto che contiene una risposta simulata per la chiamata [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)a una funzione Lambda:
```
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
```
##### Lancia
`Throw`è rappresentato come un campo degli `MockedResponse` oggetti. Specifica l'[output di errore](concepts-error-handling.md) di un'operazione non riuscita. Il valore di `Throw` deve essere un oggetto contenente un `Error` e `Cause` campi con valori di stringa. Inoltre, il valore di stringa specificato nel `Error` campo in `MockConfigFile.json` deve corrispondere agli errori gestiti nelle `Catch` sezioni `Retry` e della macchina a stati.
Di seguito è riportato un esempio di `Throw` oggetto che contiene una risposta simulata per la chiamata [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)a una funzione Lambda:
```
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
```