Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Testen von Zustandsmaschinen mit TestState API
**Anmerkung**
Ab November 2025 enthält die TestState API Verbesserungen, mit denen Sie automatisierte Komponententests für Ihre AWS Step Functions Functions-Workflows erstellen können. Diese Verbesserungen sind über AWS CLI und verfügbar SDKs. Die wichtigsten Verbesserungen wurden hinzugefügt:
Simulieren Sie AWS Dienstintegrationen oder Dienste, die über den HTTP-Aufgabenstatus aufgerufen werden, um die Statuslogik zu testen, ohne den eigentlichen Dienst aufzurufen
Testen Sie erweiterte Status wie „Map“, „Parallel“ und „Aktivität“ mit simulierten Antworten
Steuern Sie den Ausführungskontext, um bestimmte Wiederholungsversuche zu testen, Iterationspositionen zuzuordnen und Fehlerszenarien zu erstellen
## -Übersicht
Sie können einen [unterstützten Status](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html#supported-test-states) mithilfe der TestState Funktion in der Step Functions Konsole oder im AWSCommand Line Interface (AWS CLI) SDK testen.
Die [TestState](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html)API akzeptiert die Definition eines Status und führt sie aus. Sie ermöglicht es Ihnen, einen Status zu testen, ohne eine Zustandsmaschine zu erstellen oder eine bestehende Zustandsmaschine zu aktualisieren. Sie können Folgendes bereitstellen:
+ Eine einzige Bundesstaatendefinition
+ Eine vollständige Zustandsmaschinen-Definition mit `stateName` Parametern
Die `TestState` API übernimmt eine IAM Rolle, die die erforderlichen IAM Berechtigungen für die Ressourcen enthalten muss, auf die Ihr Staat zugreift. Wenn Sie ein Modell angeben, wird die Angabe der Rolle optional, sodass Sie die Logik der Zustandsmaschine testen können, ohne IAM Berechtigungen konfigurieren zu müssen. Informationen zu den Berechtigungen, die ein Staat möglicherweise benötigt, finden Sie unter[IAMBerechtigungen für die Verwendung der TestState API](#test-state-permissions).
**Topics**
+ [Verwenden von Inspektionsebenen in der TestState API](#how-test-state-works)
+ [IAMBerechtigungen für die Verwendung der TestState API](#test-state-permissions)
+ [Testen eines Zustands mit der AWS Step Functions Functions-Konsole](#test-state-console)
+ [Testen eines Zustands mit AWS CLI](#test-state-cli)
+ [Testen und Debuggen des Eingabe- und Ausgabedatenflusses](#test-state-input-output-dataflow)
+ [Was Sie mit der API testen und bestätigen können TestState](#what-you-can-test-assert)
+ [Verspottete Serviceintegrationen](#mocking-service-integrations)
+ [Status „Map“ und „Parallel“ testen](#testing-map-parallel-states)
+ [Aktivität testen, .sync und. waitForTaskToken-Status](#testing-activity-sync-waitfortasktoken)
+ [Iteration durch Zustandsmaschinendefinitionen](#iterating-through-state-machine-definitions)
+ [Verwenden Sie das Kontextfeld in der TestState API](#using-context-field)
+ [Testen von Wiederholungsversuchen und Fehlerbehandlung](#testing-retry-error-handling)
## Verwenden von Inspektionsebenen in der TestState API
Wenn Sie einen Status mithilfe der [TestState](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html)API testen, können Sie angeben, wie viele Details Sie in den Testergebnissen anzeigen möchten. Wenn Sie beispielsweise Eingabe- und Ausgabedatenverarbeitungsfilter wie [`InputPath`](input-output-inputpath-params.md#input-output-inputpath)oder verwendet haben [`ResultPath`](input-output-resultpath.md), können Sie die Zwischen- und Enddaten der Datenverarbeitung einsehen. Step Functionsbietet die folgenden Inspektionsstufen:
+ [INFORMATIONEN](#test-state-info-level)
+ [DEBUGGEN](#test-state-debug-level)
+ [VERFOLGEN](#test-state-trace-level)
Alle diese Ebenen geben auch die `nextState` Felder `status` und zurück. `status`gibt den Status der Ausführung im Status an. Zum Beispiel`SUCCEEDED`, `FAILED``RETRIABLE`, und`CAUGHT_ERROR`. `nextState`gibt den Namen des nächsten Zustands an, zu dem der Übergang erfolgen soll. Wenn Sie in Ihrer Definition keinen nächsten Status definiert haben, gibt dieses Feld einen leeren Wert zurück.
Informationen zum Testen eines Zustands mithilfe dieser Inspektionsstufen in der Step Functions Konsole und AWS CLI finden Sie unter [Testen eines Zustands mit der AWS Step Functions Functions-Konsole](#test-state-console) und[Testen eines Zustands mit AWS CLI](#test-state-cli).
### INFO: InspektionLevel
Wenn der Test erfolgreich ist, zeigt diese Stufe die Statusausgabe an. Wenn der Test fehlschlägt, zeigt diese Stufe die Fehlerausgabe an. Step FunctionsLegt die **Inspektionsstufe** standardmäßig auf **INFO** fest, wenn Sie keine Stufe angeben.
#### Beispiel für einen Test mit der Stufe INFO, der erfolgreich ist
Die folgende Abbildung zeigt einen Test für den Status „Bestanden“, der erfolgreich war. Die **Inspektionsstufe** für diesen Status ist auf **INFO** festgelegt, und die Ausgabe für den Status wird auf der Registerkarte **Ausgabe** angezeigt.
![\[Screenshot der Ausgabe auf INFO-Ebene für einen bestandenen Test.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/test-state-info-success.png)
#### Beispiel für einen Test mit INFO-Stufe, der fehlschlägt
Die folgende Abbildung zeigt einen Test, der für einen Task-Status fehlgeschlagen ist, wenn die **Inspektionsebene auf** **INFO** gesetzt ist. Auf der Registerkarte **Ausgabe** wird die Fehlerausgabe angezeigt, die den Fehlernamen und eine ausführliche Erklärung der Fehlerursache enthält.
![\[Screenshot der Ausgabe auf INFO-Ebene für einen fehlgeschlagenen Test.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/test-state-info-failed.png)
### DEBUG InspectionLevel
Wenn der Test erfolgreich ist, zeigt diese Stufe die Statusausgabe und das Ergebnis der Eingabe- und Ausgabedatenverarbeitung an.
Schlägt der Test fehl, zeigt diese Stufe die Fehlerausgabe an. Auf dieser Ebene werden die Zwischenergebnisse der Datenverarbeitung bis zum Zeitpunkt des Fehlers angezeigt. Angenommen, Sie haben einen Task-Status getestet, der eine Lambda Funktion aufruft. Stellen Sie sich vor, Sie hätten die [Filtern der Statusausgabe mit OutputPath](input-output-example.md#input-output-outputpath) Filter [InputPath](input-output-inputpath-params.md#input-output-inputpath)[Parameters](input-output-inputpath-params.md#input-output-parameters),[Zustandsausgabe mithilfe von ResultPath In-Step-Funktionen angeben](input-output-resultpath.md), und auf den Status Task angewendet. Angenommen, der Aufruf ist fehlgeschlagen. In diesem Fall zeigt die `DEBUG` Ebene die Datenverarbeitungsergebnisse, die auf der Anwendung der Filter basieren, in der folgenden Reihenfolge an:
+ `input`— Eingabe im Rohzustand
+ `afterInputPath`— Eingabe nach der Step Functions Anwendung des `InputPath` Filters.
+ `afterParameters`— Die effektive Eingabe danach Step Functions wendet den `Parameters` Filter an.
Die auf dieser Ebene verfügbaren Diagnoseinformationen können Ihnen bei der Behebung von Problemen im Zusammenhang mit einer [Serviceintegration](integrate-services.md) oder einem von Ihnen definierten Ablauf der [Eingabe- und Ausgabedatenverarbeitung](#test-state-input-output-dataflow) helfen.
#### Beispiel für einen erfolgreichen Test mit DEBUG-Stufe
Die folgende Abbildung zeigt einen Test für den Status „Bestanden“, der erfolgreich war. Die **Inspektionsstufe** für diesen Status ist auf **DEBUG** gesetzt. Die Registerkarte **Eingabe-/Ausgabeverarbeitung** in der folgenden Abbildung zeigt das Ergebnis der Anwendung von [`Parameters`](input-output-inputpath-params.md#input-output-parameters)auf die für diesen Status bereitgestellte Eingabe.
![\[Screenshot der Ausgabe auf DEBUG-Ebene für einen bestandenen Test.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/test-state-debug-success.png)
#### Beispiel für einen Test mit DEBUG-Stufe, der fehlschlägt
Die folgende Abbildung zeigt einen Test, der für einen Task-Status fehlgeschlagen ist, wenn die **Inspektionsebene auf** **DEBUG** gesetzt ist. Die Registerkarte **Eingabe-/Ausgabeverarbeitung** in der folgenden Abbildung zeigt das Ergebnis der Eingabe- und Ausgabedatenverarbeitung für den Status bis zum Zeitpunkt des Fehlers.
![\[Screenshot der Ausgabe auf DEBUG-Ebene für einen fehlgeschlagenen Test.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/test-state-debug-failed.png)
### TRACE InspectionLevel
Step Functionsstellt die **TRACE-Stufe** zum Testen einer [HTTP-Task](call-https-apis.md) bereit. Diese Ebene gibt Informationen über die HTTP-Anfrage zurück, die gestellt Step Functions wird, und über die Antwort, die eine HTTPS-API zurückgibt. Die Antwort kann Informationen wie Header und den Hauptteil der Anfrage enthalten. Darüber hinaus können Sie den Status, die Ausgabe und das Ergebnis der Eingabe- und Ausgabedatenverarbeitung auf dieser Ebene anzeigen.
Wenn der Test fehlschlägt, zeigt diese Stufe die Fehlerausgabe an.
Diese Stufe gilt nur für HTTP-Tasks. Step Functionsgibt einen Fehler aus, wenn Sie diese Ebene für andere Statustypen verwenden.
Wenn Sie die **Inspektionsebene auf** **TRACE** setzen, können Sie auch die in der [EventBridge Verbindung](call-https-apis.md#http-task-authentication) enthaltenen Geheimnisse anzeigen. Dazu müssen Sie den `revealSecrets` Parameter `true` in der [TestState](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html)API auf setzen. Darüber hinaus müssen Sie sicherstellen, dass der IAM Benutzer, der die TestState API aufruft, über die Berechtigung für die `states:RevealSecrets` Aktion verfügt. Ein Beispiel für eine IAM Richtlinie, die die `states:RevealSecrets` Berechtigung festlegt, finden Sie unter[IAMBerechtigungen für die Verwendung der TestState API](#test-state-permissions). Ohne diese Berechtigung wird der Fehler Step Functions „Zugriff verweigert“ ausgegeben.
Wenn Sie den `revealSecrets` Parameter auf setzen`false`, werden alle Geheimnisse in den HTTP-Anforderungs- und Antwortdaten Step Functions weggelassen. Beachten Sie, dass Sie diese Option nicht verwenden können`revealSecrets`, wenn Mocking aktiviert ist. Wenn Sie in der TestState API-Anfrage beides `revealSecrets` und einen Mock angeben, wird eine Validierungsausnahme Step Functions zurückgegeben.
#### Beispiel für einen Test mit TRACE-Stufe, der erfolgreich ist
Die folgende Abbildung zeigt einen erfolgreichen Test für eine HTTP-Aufgabe. Die **Inspektionsebene** für diesen Status ist auf **TRACE** festgelegt. Die Registerkarte „**HTTP-Anfrage und Antwort**“ in der folgenden Abbildung zeigt das Ergebnis des HTTPS-API-Aufrufs.
![\[Screenshot der Ausgabe auf TRACE-Ebene für einen bestandenen Test.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/test-state-trace-success.png)
## IAMBerechtigungen für die Verwendung der TestState API
Der IAM Benutzer, der die `TestState` API aufruft, muss über die Berechtigung verfügen, die `states:TestState` Aktion auszuführen. Wenn Sie Mocking nicht verwenden, muss der IAM Benutzer auch über die Berechtigung verfügen, die `iam:PassRole` Aktion auszuführen, an die er die Ausführungsrolle übergeben sollStep Functions. Wenn Sie den `revealSecrets` Parameter auf setzen`true`, muss der IAM Benutzer außerdem über die Berechtigung verfügen, die `states:RevealSecrets` Aktion auszuführen. Ohne diese Berechtigung wird der Fehler Step Functions „Zugriff verweigert“ ausgegeben.
Beachten Sie, dass Sie, wenn Sie in der TestState API-Anfrage ein Modell angeben, Ihre Zustandsmaschinenlogik testen können, ohne eine Ausführungsrolle anzugeben (weitere Informationen finden Sie unter [Mocking-Dienstintegrationen](#mocking-service-integrations)). Wenn Sie keine Mocks verwenden, müssen Sie eine Ausführungsrolle angeben, die die erforderlichen Berechtigungen für die Ressourcen enthält, auf die Ihr Staat zugreift. Informationen zu den Berechtigungen, die Ihr Bundesstaat möglicherweise benötigt, finden Sie unter [Ausführungsrollen verwalten](manage-state-machine-permissions.md).
## Testen eines Zustands mit der AWS Step Functions Functions-Konsole
Sie können einen Status in der Konsole testen und die Statusausgabe oder den Ablauf der Eingabe- und Ausgabedatenverarbeitung überprüfen. Bei einer [HTTP-Aufgabe](call-https-apis.md) können Sie die rohe HTTP-Anfrage und -Antwort testen.
**Anmerkung**
Die TestState Konsolenfunktion unterstützt einige der in diesem Dokument beschriebenen Verbesserungen noch nicht, wie z. B. das Nachmachen von Service-Integrationen, das Testen von Map- und Parallel-Status oder Activity, .sync und. waitForTaskToken-Muster. Diese Funktionen sind derzeit nur über die TestState API mit dem SDK AWS CLI oder verfügbar.
**Um einen Status zu testen**
1. Öffnen Sie die [Step Functions Functions-Konsole](https://console.aws.amazon.com/states/home?region=us-east-1#/).
1. Wählen Sie **Create State Machine**, um mit der Erstellung eines State Machine zu beginnen, oder wählen Sie einen vorhandenen State Machine aus.
1. Wählen Sie im [Entwurfsmodus](workflow-studio.md#wfs-interface-design-mode) Workflow Studio einen Status aus, den Sie testen möchten.
1. Wählen Sie im Workflow Studio [Inspektor-Panel](workflow-studio.md#workflow-studio-components-formdefinition) den **Teststatus** aus.
1. Gehen Sie im Dialogfeld **Teststatus** wie folgt vor:
1. Wählen Sie **unter Ausführungsrolle** eine Ausführungsrolle aus, um den Status zu testen. Stellen Sie sicher, dass Sie über die erforderlichen [IAMBerechtigungen](#test-state-permissions) für den Status verfügen, den Sie testen möchten.
1. (Optional) Geben Sie alle JSON-Eingaben an, die Ihr ausgewählter Bundesstaat für den Test benötigt.
1. Wählen Sie für **Inspektionsebene** je nach den Werten, die Sie anzeigen möchten, eine der folgenden Optionen aus:
+ [INFO](#test-state-info-level) — Zeigt die Statusausgabe auf der Registerkarte „**Ausgabe**“ an, wenn der Test erfolgreich ist. Wenn der Test fehlschlägt, zeigt **INFO** die Fehlerausgabe an, die den Fehlernamen und eine detaillierte Erklärung der Fehlerursache enthält. Step FunctionsLegt standardmäßig die **Inspektionsstufe auf** **INFO** fest, wenn Sie keine Stufe auswählen.
+ [DEBUG](#test-state-debug-level) — Zeigt die Statusausgabe und das Ergebnis der Eingabe- und Ausgabedatenverarbeitung an, wenn der Test erfolgreich ist. Wenn der Test fehlschlägt, zeigt **DEBUG** die Fehlerausgabe an, die den Fehlernamen und eine detaillierte Erklärung der Fehlerursache enthält.
+ [TRACE](#test-state-trace-level) — Zeigt die rohe HTTP-Anfrage und -Antwort an und ist nützlich für die Überprüfung von Headern, Abfrageparametern und anderen API-spezifischen Details. [Diese Option ist nur für den HTTP-Task verfügbar.](call-https-apis.md)
Optional können Sie die Option **Geheimnisse enthüllen** auswählen. In Kombination mit **TRACE** können Sie mit dieser Einstellung die vertraulichen Daten sehen, die die EventBridge Verbindung einfügt, z. B. API-Schlüssel. Die IAM Benutzeridentität, die Sie für den Zugriff auf die Konsole verwenden, muss berechtigt sein, die `states:RevealSecrets` Aktion auszuführen. Ohne diese Berechtigung wird beim Starten des Tests die Fehlermeldung „Zugriff verweigert“ ausgegeben. Step Functions Ein Beispiel für eine IAM Richtlinie, die die `states:RevealSecrets` Berechtigung festlegt, finden Sie unter[IAMBerechtigungen für die Verwendung der TestState API](#test-state-permissions).
1. Wählen Sie **Test starten** aus.
## Testen eines Zustands mit AWS CLI
Sie können einen Status mithilfe der [TestState](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html)API in der testenAWS CLI. Diese API akzeptiert die Definition eines Zustands und führt sie aus.
Für jeden Status können Sie angeben, wie viele Details Sie in den Testergebnissen anzeigen möchten. Diese Details enthalten zusätzliche Informationen über die Ausführung des Status, einschließlich der Ergebnisse der Eingabe- und Ausgabedatenverarbeitung sowie Informationen zur HTTP-Anforderung und -Antwort. Die folgenden Beispiele zeigen die verschiedenen Inspektionsstufen, die Sie für die TestState API angeben können.
Dieser Abschnitt enthält die folgenden Beispiele, in denen beschrieben wird, wie Sie die verschiedenen Inspektionsebenen verwenden können, die Folgendes Step Functions bietenAWS CLI:
+ [Verwenden von INFO InspectionLevel](#test-info-level-cli)
+ [Verwenden von DEBUG InspectionLevel](#test-debug-level-cli)
+ [Verwenden von TRACE InspectionLevel](#test-trace-level-cli)
+ [Verwenden Sie das jq-HilfsprogrammAWS CLI, um die von der API zurückgegebene HTTP-Antwort zu filtern und zu drucken TestState ](#cli-readable-output)
### Beispiel 1: Verwenden von INFO InspectionLevel zum Testen eines Choice-Status
Um einen Status mithilfe des `INFO` [InspectionLevels](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html#StepFunctions-TestState-request-inspectionLevel) in der zu testenAWS CLI, führen Sie den `test-state` Befehl wie im folgenden Beispiel gezeigt aus.
```
aws stepfunctions test-state \
--definition '{"Type": "Choice", "Choices": [{"Variable": "$.number", "NumericEquals": 1, "Next": "Equals 1"}, {"Variable": "$.number", "NumericEquals": 2, "Next": "Equals 2"}], "Default": "No Match"}' \
--role-arn arn:aws:iam::account-id:role/myRole \
--input '{"number": 2}'
```
In diesem Beispiel wird der Status [Choice](state-choice.md) verwendet, um den Ausführungspfad für den Status anhand der von Ihnen angegebenen numerischen Eingabe zu ermitteln. Step FunctionsLegt den Wert standardmäßig `inspectionLevel` auf fest, `INFO` wenn Sie keine Stufe festlegen.
Step Functionsgibt die folgende Ausgabe zurück.
```
{
"output": "{\"number\": 2}",
"nextState": "Equals 2",
"status": "SUCCEEDED"
}
```
### Beispiel 2: Verwendung von DEBUG InspectionLevel zum Debuggen der Eingabe- und Ausgabedatenverarbeitung im Status Pass
Um einen Status mit dem `DEBUG` [InspectionLevel](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html#StepFunctions-TestState-request-inspectionLevel) in der zu testenAWS CLI, führen Sie den `test-state` Befehl aus, wie im folgenden Beispiel gezeigt.
```
aws stepfunctions test-state \
--definition '{"Type": "Pass", "InputPath": "$.payload", "Parameters": {"data": 1}, "ResultPath": "$.result", "OutputPath": "$.result.data", "Next": "Another State"}' \
--role-arn arn:aws:iam::account-id:role/myRole \
--input '{"payload": {"foo": "bar"}}' \
--inspection-level DEBUG
```
In diesem Beispiel wird anhand eines [Workflow-Status übergeben](state-pass.md) Status veranschaulicht, wie JSON-Eingabedaten mithilfe der Eingabe- und Step Functions Ausgabedatenverarbeitungsfilter gefiltert und bearbeitet werden. In diesem Beispiel werden die folgenden Filter verwendet:`InputPath`, `Parameters``Zustandsausgabe mithilfe von ResultPath In-Step-Funktionen angeben`, und. `Filtern der Statusausgabe mit OutputPath`
Step Functionsgibt die folgende Ausgabe zurück.
```
{
"output": "1",
"inspectionData": {
"input": "{\"payload\": {\"foo\": \"bar\"}}",
"afterInputPath": "{\"foo\":\"bar\"}",
"afterParameters": "{\"data\":1}",
"afterResultSelector": "{\"data\":1}",
"afterResultPath": "{\"payload\":{\"foo\":\"bar\"},\"result\":{\"data\":1}}"
},
"nextState": "Another State",
"status": "SUCCEEDED"
}
```
### Beispiel 3: Verwendung von TRACE InspectionLevel und RevealSecrets zur Überprüfung der an eine HTTPS-API gesendeten HTTP-Anfrage
Um einen [HTTP-Task](call-https-apis.md) mithilfe von `TRACE` [InspectionLevel](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html#StepFunctions-TestState-request-inspectionLevel) zusammen mit dem Parameter [RevealSecrets](https://docs.aws.amazon.com/step-functions/latest/apireference/API_TestState.html#StepFunctions-TestState-request-revealSecrets) in der zu testenAWS CLI, führen Sie den Befehl aus, wie im folgenden Beispiel gezeigt. `test-state`
```
aws stepfunctions test-state \
--definition '{"Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": {"Method": "GET", "Authentication": {"ConnectionArn": "arn:aws:events:region:account-id:connection/MyConnection/0000000-0000-0000-0000-000000000000"}, "ApiEndpoint": "https://httpbin.org/get", "Headers": {"definitionHeader": "h1"}, "RequestBody": {"message": "Hello from Step Functions!"}, "QueryParameters": {"queryParam": "q1"}}, "End": true}' \
--role-arn arn:aws:iam::account-id:role/myRole \
--inspection-level TRACE \
--reveal-secrets
```
In diesem Beispiel wird getestet, ob der HTTP-Task die angegebene HTTPS-API aufruft,. `https://httpbin.org/` Außerdem werden die HTTP-Anfrage- und Antwortdaten für den API-Aufruf angezeigt.
Step Functionsgibt eine Ausgabe zurück, die dem ursprünglichen Beispiel in der aktuellen Dokumentation ähnelt.
### Beispiel 4: Verwenden des jq-Dienstprogramms zum Filtern und Drucken der von der TestState API zurückgegebenen Antwort
Die TestState API gibt JSON-Daten in ihrer Antwort als Escape-Zeichenketten zurück. Das folgende AWS CLI Beispiel erweitert [Beispiel 3](#test-trace-level-cli) und verwendet das `jq` Hilfsprogramm, um die von der TestState API zurückgegebene HTTP-Antwort in einem für Menschen lesbaren Format zu filtern und auszudrucken. Weitere Informationen `jq` und Installationsanweisungen finden Sie unter [jq](https://stedolan.github.io/jq/) on. *GitHub*
```
aws stepfunctions test-state \
--definition '{"Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": {"Method": "GET", "Authentication": {"ConnectionArn": "arn:aws:events:region:account-id:connection/MyConnection/0000000-0000-0000-0000-000000000000"}, "ApiEndpoint": "https://httpbin.org/get", "Headers": {"definitionHeader": "h1"}, "RequestBody": {"message": "Hello from Step Functions!"}, "QueryParameters": {"queryParam": "q1"}}, "End": true}' \
--role-arn arn:aws:iam::account-id:role/myRole \
--inspection-level TRACE \
--reveal-secrets \
| jq '.inspectionData.response.body | fromjson'
```
Das folgende Beispiel zeigt die Ausgabe, die in einem für Menschen lesbaren Format zurückgegeben wird.
```
{
"args": {
"QueryParam1": "QueryParamValue1",
"queryParam": "q1"
},
"headers": {
"Authorization": "Basic XXXXXXXX",
"Content-Type": "application/json; charset=UTF-8",
"Customheader1": "CustomHeaderValue1",
"Definitionheader": "h1",
"Host": "httpbin.org",
"Range": "bytes=0-262144",
"Transfer-Encoding": "chunked",
"User-Agent": "Amazon|StepFunctions|HttpInvoke|region",
"X-Amzn-Trace-Id": "Root=1-0000000-0000-0000-0000-000000000000"
},
"origin": "12.34.567.891",
"url": "https://httpbin.org/get?queryParam=q1&QueryParam1=QueryParamValue1"
}
```
## Testen und Debuggen des Eingabe- und Ausgabedatenflusses
Die `TestState` API ist hilfreich beim Testen und Debuggen der Daten, die durch Ihren Workflow fließen. Dieser Abschnitt enthält einige wichtige Konzepte und erklärt, wie Sie die TestState für diesen Zweck verwenden können.
### Die wichtigsten Konzepte
In Step Functions wird der Prozess des Filterns und Manipulierens von JSON-Daten beim Durchlaufen der Zustände in Ihrer Zustandsmaschine als *Eingabe- und Ausgabeverarbeitung* bezeichnet. Weitere Information zur Funktionsweise finden Sie unter [Eingabe und Ausgabe in Step Functions verarbeiten](concepts-input-output-filtering.md).
Alle [Zustandstypen](workflow-states.md) in der [Sprache der Amazonas-Staaten](concepts-amazon-states-language.md) (ASL) (Task, Parallel, Map, Pass, Wait, Choice, Succeed und Fail) haben gemeinsam eine Reihe gemeinsamer Felder zum Filtern und Bearbeiten der JSON-Daten, die sie durchlaufen. Diese Felder sind:[InputPath](input-output-inputpath-params.md#input-output-inputpath),, [Parameters](input-output-inputpath-params.md#input-output-parameters) [ResultSelector](input-output-inputpath-params.md#input-output-resultselector)[Zustandsausgabe mithilfe von ResultPath In-Step-Funktionen angeben](input-output-resultpath.md), und. [Filtern der Statusausgabe mit OutputPath](input-output-example.md#input-output-outputpath) Die Support für jedes Feld [ist von Bundesstaat zu Bundesstaat unterschiedlich](https://states-language.net/spec.html#state-type-table). Step FunctionsWendet zur Laufzeit jedes Feld in einer bestimmten Reihenfolge an. Das folgende Diagramm zeigt die Reihenfolge, in der diese Felder auf die Daten innerhalb eines Task-Status angewendet werden:
![\[Reihenfolge der Filter: InputPath, Parameter ResultSelector, ResultPath, und OutputPath.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/input-output-processing.png)
In der folgenden Liste wird die Reihenfolge beschrieben, in der die Eingabe- und Ausgabeverarbeitungsfelder im Diagramm angewendet werden.
1. Bei der *Statuseingabe* handelt es sich um die JSON-Daten, die von einem früheren Status an den aktuellen Status übergeben wurden.
1. [InputPath](input-output-inputpath-params.md#input-output-inputpath)filtert einen Teil der Rohstatuseingabe.
1. [Parameters](input-output-inputpath-params.md#input-output-parameters)konfiguriert den Wertesatz, der an die [Aufgabe](state-task.md) übergeben werden soll.
1. Die Aufgabe führt Arbeit aus und gibt ein Ergebnis zurück.
1. [ResultSelector](input-output-inputpath-params.md#input-output-resultselector)wählt eine Reihe von Werten aus, die aus dem Aufgabenergebnis übernommen werden sollen.
1. [Zustandsausgabe mithilfe von ResultPath In-Step-Funktionen angeben](input-output-resultpath.md)kombiniert das Ergebnis mit der unverarbeiteten Statuseingabe oder ersetzt das Ergebnis damit.
1. [Filtern der Statusausgabe mit OutputPath](input-output-example.md#input-output-outputpath)filtert einen Teil der Ausgabe, sodass er in den nächsten Zustand übergeht.
1. Bei der *Statusausgabe* handelt es sich um die JSON-Daten, die vom aktuellen Status an den nächsten Status übergeben werden.
Diese Eingabe- und Ausgabeverarbeitungsfelder sind optional. Wenn Sie keines dieser Felder in Ihrer Bundesstaatendefinition verwenden, verwendet die Aufgabe die unverarbeitete Statuseingabe und gibt das Aufgabenergebnis als Statusausgabe zurück.
### Wird verwendet TestState , um die Eingabe- und Ausgabeverarbeitung zu überprüfen
Wenn Sie die `TestState` API aufrufen und den `inspectionLevel` Parameter auf setzen`DEBUG`, enthält die API-Antwort ein aufgerufenes Objekt`inspectionData`. Dieses Objekt enthält Felder, anhand derer Sie überprüfen können, wie Daten innerhalb des Status gefiltert oder manipuliert wurden, als sie ausgeführt wurden. Das folgende Beispiel zeigt das `inspectionData` Objekt für einen Task-Status.
```
"inspectionData": {
"input": string,
"afterInputPath": string,
"afterParameters": string,
"result": string,
"afterResultSelector": string,
"afterResultPath": string,
"output": string
}
```
In diesem Beispiel zeigt jedes Feld, das das `after` Präfix enthält, die Daten an, nachdem ein bestimmtes Feld angewendet wurde. `afterInputPath`Zeigt beispielsweise, wie sich das Anwenden des `InputPath` Felds auf das Filtern der Rohstatuseingabe auswirkt. Das folgende Diagramm ordnet jedes [ASL-Definitionsfeld](concepts-amazon-states-language.md) dem entsprechenden Feld im `inspectionData` Objekt zu:
![\[Diagramm, das die Zuordnung von ASL-Feldern zu InspectionData zeigt.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/inspection-data-after-fields.png)
Beispiele für die Verwendung der TestState API zum Debuggen der Eingabe- und Ausgabeverarbeitung finden Sie im Folgenden:
+ [Testen eines Zustands mithilfe der DEBUG-Inspektionsebene in der Konsole Step Functions](#test-state-debug-level)
+ [Testen eines Zustands mithilfe der DEBUG-Inspektionsebene in AWS CLI](#test-debug-level-cli)
Speziell für Map-Status enthält das `inspectionData` Objekt, wenn auf festgelegt `inspectionLevel` ist`DEBUG`, zusätzliche Felder, anhand derer Sie überprüfen können, wie der Map-Status Elemente extrahiert und transformiert. Weitere Informationen zu diesen Feldern finden Sie im Abschnitt [Grundlegendes zu Inspektionsdaten für den Kartenstatus](#understanding-map-inspection-data).
### Informationen zu den Inspektionsdaten des Kartenzustands
Wenn Sie einen Map-Status mit der `inspectionLevel` Einstellung auf testen`DEBUG`, enthält die TestState API-Antwort zusätzliche Felder im `inspectionData` Objekt, die zeigen, wie Ihr Map-Status Daten verarbeitet:
**Anmerkung**
`afterItemsPath`wird nur aufgefüllt, wenn es JSONPath als Abfragesprache verwendet wird.
+ `afterItemsPath`(Zeichenfolge) — Die effektive Eingabe, nachdem der ItemsPath Filter angewendet wurde. Dies zeigt die Reihe von Elementen, die aus Ihrer Eingabe extrahiert wurden.
+ `afterItemsPointer`(String) — Die effektive Eingabe, nachdem der ItemsPointer Filter angewendet wurde. Dies gilt nur für JSON-Eingaben (nicht JSONata).
+ `afterItemSelector`(Array of Strings) — Ein Array, das die Eingabewerte nach der Anwendung der ItemSelector Transformation enthält. Jedes Element im Array steht für ein transformiertes Element. Dieses Feld ist nur vorhanden, wenn ein Map-Status getestet wird.
+ `afterItemBatcher`(Array of Strings) — Ein Array, das die Eingabewerte enthält, nachdem die ItemBatcher Gruppierung angewendet wurde. Dies zeigt, wie Elemente zu Stapeln gruppiert werden. Dieses Feld ist nur vorhanden, wenn ein Map-Status getestet wird.
+ `toleratedFailureCount`(Zahl) — Der tolerierte Fehlerschwellenwert für einen Map-Status, ausgedrückt als Anzahl von Map-State-Iterationen. Dieser Wert wird entweder aus dem in angegebenen Wert ToleratedFailureCount oder aus dem Wert abgeleitet, der zur Laufzeit von ToleratedFailureCountPath ausgewertet wurde.
+ `toleratedFailurePercentage`(Zahl) — Der tolerierte Ausfallschwellenwert für einen Map-Status, ausgedrückt als Prozentsatz der Map-State-Iterationen. Dieser Wert wird entweder aus dem in angegebenen Wert ToleratedFailurePercentage oder aus dem Wert abgeleitet, der zur Laufzeit von ToleratedFailurePercentagePath ausgewertet wurde.
+ `maxConcurrency`(Zahl) — Die maximale Parallelitätseinstellung des Map-Status.
Mit diesen Feldern können Sie vor der Bereitstellung überprüfen, ob die Datentransformationen und Fehlertoleranzkonfigurationen Ihres Map-Status ordnungsgemäß funktionieren.
## Was Sie mit der API testen und bestätigen können TestState
Die TestState API ermöglicht es Ihnen, umfassende Komponententests für Ihre Zustandsmaschinen zu schreiben. Sie können sich auf mehrere Aspekte Ihrer Zustandsmaschinenlogik verlassen, darunter die folgenden:
+ [Fehlerbehandlung: Welcher Catch oder Retry gilt](#error-handling-catch-retry)
+ [Datentransformationen: Eingabe- und Ausgabeverarbeitung](#data-transformations-assert)
+ [Zustandstransformationen zuordnen: ItemSelector,, ItemsPath, ItemBatcher ItemsPointer](#map-state-transformations-assert)
+ [Zuordnen der Schwellenwerte für Statusausfälle: Teststatus. ExceedToleratedFailureThreshold](#map-failure-thresholds-assert)
+ [Fehlerausbreitung in den Zuständen Map und Parallel](#error-propagation-assert)
### Fehlerbehandlung: Welcher Catch oder Retry gilt
Wenn Sie sich über einen Fehler lustig machen, können Sie mithilfe der TestState API nachsehen, welcher Fehlerhandler aktiviert wird.
Bei Catch-Blöcken können Sie Folgendes behaupten:
+ Welcher Catch-Handler fängt den Fehler ab (über `catchIndex` in der Antwort)
+ Was wird der nächste Status sein (via `nextState` in der Antwort)
+ Welche Daten fließen an den Fehlerhandler (via `output` in der Antwort, wenn man bedenkt ResultPath)
Bei Wiederholungsblöcken können Sie Folgendes bestätigen:
+ Welcher Wiederholungsversuch gilt (über `retryIndex` in der Antwort)
+ Wie lang ist die Backoff-Dauer (via `retryBackoffIntervalSeconds` in der Antwort)
+ Ob die Wiederholungsversuche erschöpft sind und der Fehler abgefangen wird
### Datentransformationen: Eingabe- und Ausgabeverarbeitung
Mithilfe der TestState API können Sie überprüfen, wie Ihre Bundesstaatsdaten in jeder Phase der Verarbeitung transformiert werden.
Sie können Folgendes behaupten:
+ Eingabe nach InputPath Filter (`afterInputPath`)
+ Daten nach der Parameters/Arguments Transformation (`afterParameters`oder`afterArguments`)
+ Ergebnis nach ResultSelector (`afterResultSelector`)
+ Ausgabe nach ResultPath (`afterResultPath`)
+ Endgültige Ausgabe nach OutputPath (`output`)
### Zustandstransformationen zuordnen: ItemSelector,, ItemsPath, ItemBatcher ItemsPointer
Für Map-Status können Sie die TestState API verwenden, um zu sehen, wie Elemente extrahiert und transformiert werden.
Sie können Folgendes behaupten:
+ Elemente nach dem ItemsPath Filter (`afterItemsPath`)
+ Artikel nach dem ItemsPointer Filter (`afterItemsPointer`)
+ Elemente nach der ItemSelector Transformation (`afterItemSelector`)
+ Elemente nach der ItemBatcher Gruppierung () `afterItemBatcher`
### Zuordnen der Schwellenwerte für Statusausfälle: Teststatus. ExceedToleratedFailureThreshold
Testen Sie, ob eine bestimmte Anzahl fehlgeschlagener Iterationen den Schwellenwert für tolerierte Fehler auslöst.
Sie können Folgendes behaupten:
+ Ob der Kartenstatus bei Staaten fehlschlägt. ExceedToleratedFailureThreshold
### Fehlerausbreitung in den Zuständen Map und Parallel
Beim Testen von Zuständen innerhalb von Map- oder Parallel-Zuständen werden Fehler genauso wie bei einer echten Ausführung an die Fehlerbehandlungsroutinen des übergeordneten Zustands weitergegeben.
#### Geben Sie die Fehlerquelle mit State an errorCausedBy
Wenn Sie Fehler für den Status Map oder Parallel simulieren, müssen Sie mithilfe des Parameters angeben, welcher Unterstatus den Fehler verursacht hat. `stateConfiguration.errorCausedByState` Dies ist besonders wichtig beim Testen von Platzhalterfehlern wie. `States.TaskFailed` `States.TaskFailed`ist ein Platzhalterfehler, der auf jeden Fehler im Task-Status zutrifft. Um zu testen, wie Ihr Map- oder Parallel-Status mit diesem Fehler umgeht, müssen Sie den spezifischen Unterstatus identifizieren, der den Fehler ausgelöst hat. Sehen Sie sich das Beispiel unten an:
```
aws stepfunctions test-state \
--definition '{...Map or Parallel state definition...}' \
--input '[...]' \
--state-configuration '{"errorCausedByState": "ProcessItem"}' \
--mock '{"errorOutput": {"error": "States.TaskFailed", "cause": "Task execution failed"}}'
```
In diesem Beispiel wird angegeben`errorCausedByState`, TestState dass der Status ProcessItem "" innerhalb des Map/Parallel Workflows den Fehler ausgelöst hat. Die Catch- oder Retry-Handler des übergeordneten Map/Parallel Staates verarbeiten den Fehler wie bei der eigentlichen Ausführung. Das `nextState` Feld in der Antwort zeigt, welcher Fehlerhandler den Fehler erkannt hat. Sie können Folgendes behaupten:
+ Ob Fehler im untergeordneten Status von übergeordneten Catch-Handlern abgefangen werden
+ Gibt an, ob Fehler im untergeordneten Status übergeordnete Wiederholungsrichtlinien auslösen
+ Was ist der nächste Status nach der Fehlerausbreitung
## Verspottete Serviceintegrationen
Die TestState API unterstützt das Nachahmen der Ergebnisse von Serviceintegrationen, sodass Sie Ihre State-Machine-Logik testen können, ohne tatsächliche Dienste aufrufen zu müssen. AWS
### Wann sollte Mocking verwendet werden
Spott ist nützlich für:
+ Beim Testen von Einheiten werden Maschinendefinitionen isoliert
+ Testen der Fehlerbehandlung und der Wiederholungslogik
+ Validierung von Eingabe- und Ausgabedatentransformationen
+ Simulation verschiedener Servicereaktionen und Fehlerbedingungen
+ Testen ohne Konfiguration von Berechtigungen IAM
Wenn Sie ein Modell angeben, wird der `roleArn` Parameter optional, sodass Sie sich darauf konzentrieren können, Ihre Zustandsmaschinen-Definition zu testen, ohne sich mit Problemen im Zusammenhang mit Berechtigungen befassen zu müssen.
**Anmerkung**
Mocking ist erforderlich, wenn Sie die folgenden Zustandstypen oder Serviceintegrationsmuster testen müssen: Map-, Parallel-, Activity-, .sync-Dienstintegrationen und Token-Serviceintegrationen. waitForTask
### Grundlegende Mocking-Syntax
Um ein Ergebnis der Serviceintegration zu simulieren:
```
aws stepfunctions test-state \
--definition '{
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Arguments": {
"FunctionName": "MyFunction",
"Payload.$": "$"
},
"End": true
}' \
--input '{"key": "value"}' \
--mock '{"result": "{\"Payload\": {\"statusCode\": 200, \"body\": \"Success\"}}"}'
```
Um einen Fehler zu verspotten:
```
aws stepfunctions test-state \
--definition '{
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Arguments": {...},
"End": true
}' \
--input '{"key": "value"}' \
--mock '{"errorOutput": {"error": "Lambda.ServiceException", "cause": "Service unavailable"}}'
```
**Anmerkung**
Sie können nicht beide `mock.result` und `mock.errorOutput` in demselben API-Aufruf bereitstellen. Dies führt zu einer Validierungsausnahme.
### Vorgetäuschte Validierungsmodi
Die TestState API validiert gefälschte Antworten anhand von AWS Service-API-Modellen, um deren Richtigkeit sicherzustellen. Sie können das Validierungsverhalten mit dem `fieldValidationMode` folgenden Parameter steuern:
+ **STRICT (Standard)** — Erzwingt Beschränkungen für Feldbenennung, Größe, Form und Datentyp aus AWS API-Modellen. Alle erforderlichen Felder müssen mit den richtigen Typen vorhanden sein. In diesem Modus stellen Sie sicher, dass Ihre Mocks die tatsächlichen Antworten des Kundendienstes genau wiedergeben.
+ **PRESENT** — Überprüft nur die Felder, die im Mock vorhanden sind. Unbekannte Felder werden ignoriert. Dieser Modus ist nützlich, wenn Sie Flexibilität wünschen, aber dennoch eine Validierung für bekannte Felder wünschen.
+ **KEINE** — Überspringt die Validierung vollständig. Verwenden Sie den Test mit Vorsicht, da dies zu falschen Testannahmen und zu einem Verhalten führen kann, das von den tatsächlichen Ausführungen abweicht.
**Anmerkung**
Die Validierung wird nur für Felder durchgeführt, die im AWS Service-API-Modell definiert sind. Alle Felder, die nicht im API-Modell angegeben sind, werden bei der Validierung ignoriert, unabhängig vom Validierungsmodus. Wenn Sie beispielsweise den STRICT-Modus für eine API verwenden, die keine „erforderlichen“ Felder definiert, besteht eine leere Scheinantwort die Validierung.
Beispiel mit Validierungsmodus:
```
aws stepfunctions test-state \
--definition '{
"Type": "Task",
"Resource": "arn:aws:states:::dynamodb:putItem",
"Parameters": {...},
"End": true
}' \
--input '{"key": "value"}' \
--mock '{"fieldValidationMode": "STRICT", "result": "{\"Attributes\": {...}}"}'
```
**Wichtig**
Die Scheinvalidierung wird für [HTTP-Task](call-https-apis.md) -, API Gateway-, EKS-Call- und RunJob EKS-Integrationen nicht unterstützt.
## Status „Map“ und „Parallel“ testen
Die TestState API unterstützt das Testen von Map- und Parallel-Status, wenn ein Mock angegeben ist. Auf diese Weise können Sie die Eingabe- und Ausgabeverarbeitung dieser Flow-Status testen.
### Grundlegendes zu Map-State-Tests
Wenn Sie einen Map-Status mit der TestState API testen, testen Sie die Eingabe- und Ausgabeverarbeitung des Map-Status, ohne die darin enthaltenen Iterationen auszuführen. Mit diesem Ansatz können Sie Folgendes testen:
+ ItemsPath oder ItemsPointer Extraktion aus der Eingabe
+ ItemSelector Transformation, die auf jedes Element angewendet wurde
+ ItemBatcher Gruppierung (falls angegeben)
+ Die Ausgabeverarbeitung des Kartenstatus (ResultPath, OutputPath)
+ Tolerierte Ausfallschwellenwerte
Sie testen nicht, was in den ItemProcessor (den Staaten, die jedes Element verarbeiten) passiert.
### Testen Sie einen Map-Status
Beim Testen eines Map-Status muss das simulierte Ergebnis die Ausgabe des gesamten Map-Status darstellen. Das Scheinergebnis muss je nach Ihrer Map-State-Konfiguration ein gültiges JSON-Array oder ein gültiges JSON-Objekt sein. Sehen Sie sich das Beispiel unten an:
```
aws stepfunctions test-state \
--definition '{
"Type": "Map",
"ItemsPath": "$.items",
"ItemSelector": {
"value.$": "$$.Map.Item.Value",
"index.$": "$$.Map.Item.Index"
},
"ItemProcessor": {
"ProcessorConfig": {"Mode": "INLINE"},
"StartAt": "ProcessItem",
"States": {
"ProcessItem": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"End": true
}
}
},
"End": true
}' \
--input '{"items": [1, 2, 3, 4, 5]}' \
--mock '{"result": "[10, 20, 30, 40, 50]"}' \
--inspection-level DEBUG
```
### Status auf verteilten Karten testen
Status verteilter Karten werden ähnlich wie Inline-Kartenstatus getestet. Wenn Ihre Map ein ItemReader zum Lesen aus S3 verwendet, geben Sie die Daten direkt in der Eingabe an (als ob sie bereits aus S3 gelesen worden wären). Beispiel:
```
aws stepfunctions test-state \
--definition '{
"Type": "Map",
"ItemReader": {
"Resource": "arn:aws:states:::s3:getObject",
"Parameters": {
"Bucket": "my-bucket",
"Key": "orders.json"
}
},
"ItemsPath": "$.orders",
"ItemProcessor": {
"ProcessorConfig": {"Mode": "DISTRIBUTED"},
...
},
"ToleratedFailureCount": 5,
"End": true
}' \
--input '{
"orders": [
{"orderId": "123"},
{"orderId": "456"},
{"orderId": "789"}
]
}' \
--mock '{"result": "..."}'
```
**Anmerkung**
Beim Testen des Distributed-Map-Status (Modus auf DISTRIBUTED gesetzt) können Sie auch auf mapIterationFailure Count bestätigen. Der Wert für dieses Feld darf die Anzahl der Elemente in der Eingabe nicht überschreiten und auch nicht der Anzahl der Elemente entsprechen, wenn ein Status innerhalb einer Map getestet wird.
### Automatische Kontextfüllung
Beim Testen eines Zustands innerhalb eines Map-Status (mithilfe des `stateName` Parameters) ohne Angabe eines `context` Parameters wird das Context-Objekt TestState automatisch mit Standardwerten aufgefüllt. Dazu gehören Map-spezifische Kontextfelder wie:
+ `$$.Map.Item.Index`= `0` (erste Iteration)
+ `$$.Map.Item.Value`= dein Eingabewert
+ `$$.Map.Item.Key`(für verteilte Karten mit bestimmten ItemReader Konfigurationen)
+ `$$.Map.Item.Source`(für verteilte Karten unter Angabe der Quelle des Elements)
### Parallele Zustände werden getestet
Beim Testen eines Parallelstatus muss das simulierte Ergebnis ein JSON-Array mit einem Element für jeden Zweig sein, und zwar in derselben Reihenfolge, in der die Zweige in der Definition erscheinen.
## Aktivität testen, .sync und. waitForTaskToken-Status
Die TestState API unterstützt das Testen von Aktivitätsstatus, Integrationsmustern für .sync-Dienste und. waitForTaskToken-Muster, wenn ein Mock angegeben wird. Ohne Mock wird beim Aufrufen dieser Zustände über die TestState API eine Validierungsausnahme zurückgegeben.
**Anmerkung**
Zum Testen von .sync-Integrationen mithilfe der TestState API wird die simulierte Antwort anhand des Schemas der Polling-API validiert. Beim Testen `startExecution.sync:2` muss Ihr Modell beispielsweise mit dem `DescribeExecution` Antwortschema (das den Status Step Functions abfragt) und nicht mit der Antwort übereinstimmen. `StartExecution`
## Iteration durch Zustandsmaschinendefinitionen
Sie können der TestState API eine vollständige Definition von Zustandsmaschinen zur Verfügung stellen und mithilfe des `stateName` Parameters angeben, welcher Status getestet werden soll. Auf diese Weise können Sie diesen bestimmten Status im Kontext Ihrer vollständigen Zustandsmaschine testen. Sie können Tests auch verketten, indem Sie die Ausgabe und NextState von einem Test als Eingabe zum nächsten verwenden. Auf diese Weise können Sie teilweise oder vollständige Ausführungspfade innerhalb Ihrer Zustandsmaschine testen.
## Verwenden Sie das Kontextfeld in der TestState API
Mit dem `context` Parameter können Sie Werte für das Context-Objekt angeben, die normalerweise während der Ausführung gefüllt würden. Dies ist nützlich, um Zustände zu testen, die auf Kontextwerte wie Ausführungs-ID, Statusname oder eingegebene Zeit verweisen. Das folgende Beispiel zeigt, wie Sie das Context-Objekt in Ihrem TestState API-Aufruf verwenden können:
```
aws stepfunctions test-state \
--definition '{
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Arguments": {
"FunctionName": "MyFunction",
"Payload": {
"executionId.$": "$$.Execution.Id",
"stateName.$": "$$.State.Name",
"enteredTime.$": "$$.State.EnteredTime"
}
},
"End": true
}' \
--input '{"data": "value"}' \
--context '{
"Execution": {
"Id": "arn:aws:states:us-east-1:123456789012:execution:MyStateMachine:test-exec-123",
"Name": "test-exec-123",
"StartTime": "2024-01-01T10:00:00.000Z"
},
"State": {
"Name": "ProcessData",
"EnteredTime": "2024-01-01T10:00:05.000Z"
}
}' \
--mock '{"result": "{\"status\": \"success\"}"}'
```
## Testen von Wiederholungsversuchen und Fehlerbehandlung
Mit der TestState API können Sie Wiederholungsszenarien simulieren und die Logik der Fehlerbehandlung testen, indem Sie Wiederholungsversuche und simulierte Fehler angeben.
### Simulation von Wiederholungsversuchen
```
aws stepfunctions test-state \
--definition '{
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Arguments": {...},
"Retry": [{
"ErrorEquals": ["Lambda.ServiceException"],
"IntervalSeconds": 2,
"MaxAttempts": 3,
"BackoffRate": 2.0
}],
"End": true
}' \
--input '{"data": "value"}' \
--state-configuration '{"retrierRetryCount": 1}' \
--mock '{"errorOutput": {"error": "Lambda.ServiceException", "cause": "Service error"}}' \
--inspection-level DEBUG
```
Die Antwort enthält Fehlerdetails in den InspectionData:
```
{
"status": "RETRIABLE",
"inspectionData": {
"errorDetails": {
"retryBackoffIntervalSeconds": 4,
"retryIndex": 0
}
}
}
```
Diese Antwort weist auf Folgendes hin:
+ Der Fehler ist wiederherstellbar (Status: ABRUFBAR)
+ Die Backoff-Dauer beträgt 4 Sekunden (2 × 2,0^1)
+ Der erste Wiederholungsversuch (Index 0) gilt
### Catch-Handler testen
Wenn ein Fehler verspottet wird und einem Catch-Handler entspricht, gibt das `nextState` Feld in der TestState API-Antwort an, welcher Status den Fehler behandeln wird. Im folgenden Beispiel:
Für die unten angegebene TestState API-Anfrage
```
aws stepfunctions test-state \
--definition '{
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Arguments": {...},
"Catch": [{
"ErrorEquals": ["Lambda.TooManyRequestsException"],
"ResultPath": "$.error",
"Next": "HandleThrottling"
}],
"Next": "Success"
}' \
--input '{"data": "value"}' \
--mock '{"errorOutput": {"error": "Lambda.TooManyRequestsException", "cause": "Rate exceeded"}}' \
--inspection-level DEBUG
```
Die erwartete API-Antwort sollte wie folgt lauten:
```
{
"status": "CAUGHT_ERROR",
"nextState": "HandleThrottling",
"error": "Lambda.TooManyRequestsException",
"cause": "Rate exceeded",
"output": "{\"data\": \"value\", \"error\": {\"Error\": \"Lambda.TooManyRequestsException\", \"Cause\": \"Rate exceeded\"}}",
"inspectionData": {
"errorDetails": {
"catchIndex": 0
}
}
}
```
Diese Antwort weist darauf hin, dass:
+ der Fehler wurde abgefangen (Status: CAUGHT\$1ERROR)
+ der nächste Status ist HandleThrottling
+ Die Fehlerinformation wird der Ausgabe hinzugefügt über ResultPath
+ der erste Catch-Handler (Index 0) hat den Fehler erkannt
Sie können auch testen, was passiert, wenn alle Wiederholungsversuche durch Erhöhung der RetryCount Werte in Ihrem Kontextobjekt erschöpft sind.