File di configurazione per integrazioni di servizi fittizi

Per utilizzare integrazioni di servizi fittizie, 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 simulati e le risposte simulate:

Introduzione alla struttura della configurazione fittizia

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 file di configurazione fittizio che include una StateMachine definizione eMockedResponse.

{
  "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 fittizia

Le sezioni seguenti spiegano i campi oggetto di primo livello che è necessario definire nella configurazione fittizia.

• StateMachines

• MockedResponses

StateMachines

L'StateMachinesoggetto definisce quali macchine a stati utilizzeranno integrazioni di servizi simulate. La configurazione per ogni macchina a stati è rappresentata come un campo di primo livello diStateMachines. Il nome del campo è il nome della macchina a stati e il valore è un oggetto contenente un singolo campo denominatoTestCases, 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 di TestCases rappresentano i 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 di a TestCase collega due Task stati a dueMockedResponses:

"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 chiamata di uno stato Task simulato. Si specifica il numero di chiamata utilizzando singole stringhe intere, 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 chiamata. Una risposta deve contenere un singolo campo denominato Return o Throw il cui valore è il risultato o l'errore di output della falsa chiamata Task. Se non si specifica una risposta fittizia, l'esecuzione della macchina a stati fallirà.

Di seguito è riportato un esempio di Return oggetti MockedResponse con Throw e. 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 utilizzi uno Map stato e desideri garantire risposte prevedibili per lo Map stato, imposta 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 complessivo di esecuzione degli stati tra le iterazioni. Ciò può inoltre far sì che Step Functions Local utilizzi diverse risposte simulate per gli stati di iterazione da un'esecuzione all'altra.

Return

Returnè rappresentato come un campo degli MockedResponse oggetti. 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 Invokea 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 di un'operazione fallita. Il valore di Throw deve essere un oggetto contenente Cause campi Error e con valori di stringa. Inoltre, il valore della stringa specificato nel Error campo in MockConfigFile.json deve corrispondere agli errori gestiti nelle Catch sezioni Retry e e della macchina a stati.

Di seguito è riportato un esempio di Throw oggetto che contiene una risposta simulata per la chiamata Invokea una funzione Lambda:

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

Configurazione di integrazioni di servizi fittizie

Puoi simulare qualsiasi integrazione di servizi utilizzando Step Functions Local. Tuttavia, Step Functions Local non impone che i mock siano gli stessi delle API reali. Un Task simulato non chiamerà mai l'endpoint del servizio. Se non si specifica una risposta fittizia, un Task tenterà di chiamare gli endpoint del servizio. Inoltre, Step Functions Local genererà automaticamente un task token quando si simula un task utilizzando il.waitForTaskToken.