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

-Übersicht

Sie können einen unterstützten Status mithilfe der TestState Funktion in der Step Functions Konsole oder im AWSCommand Line Interface (AWS CLI) SDK testen.

Die TestStateAPI 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:

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 unterIAMBerechtigungen für die Verwendung der TestState API.

Topics

Verwenden von Inspektionsebenen in der TestState API

Wenn Sie einen Status mithilfe der TestStateAPI testen, können Sie angeben, wie viele Details Sie in den Testergebnissen anzeigen möchten. Wenn Sie beispielsweise Eingabe- und Ausgabedatenverarbeitungsfilter wie InputPathoder verwendet haben ResultPath, können Sie die Zwischen- und Enddaten der Datenverarbeitung einsehen. Step Functionsbietet die folgenden Inspektionsstufen:

Alle diese Ebenen geben auch die nextState Felder status und zurück. statusgibt den Status der Ausführung im Status an. Zum BeispielSUCCEEDED, FAILEDRETRIABLE, undCAUGHT_ERROR. nextStategibt 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 undTesten eines Zustands mit AWS 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.

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 Filter InputPathParameters,Zustandsausgabe mithilfe von ResultPath In-Step-Funktionen angeben, 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:

Die auf dieser Ebene verfügbaren Diagnoseinformationen können Ihnen bei der Behebung von Problemen im Zusammenhang mit einer Serviceintegration oder einem von Ihnen definierten Ablauf der Eingabe- und Ausgabedatenverarbeitung helfen.

TRACE InspectionLevel

Step Functionsstellt die TRACE-Stufe zum Testen einer HTTP-Task 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 enthaltenen Geheimnisse anzeigen. Dazu müssen Sie den revealSecrets Parameter true in der TestStateAPI 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 unterIAMBerechtigungen für die Verwendung der TestState API. Ohne diese Berechtigung wird der Fehler Step Functions „Zugriff verweigert“ ausgegeben.

Wenn Sie den revealSecrets Parameter auf setzenfalse, werden alle Geheimnisse in den HTTP-Anforderungs- und Antwortdaten Step Functions weggelassen. Beachten Sie, dass Sie diese Option nicht verwenden könnenrevealSecrets, wenn Mocking aktiviert ist. Wenn Sie in der TestState API-Anfrage beides revealSecrets und einen Mock angeben, wird eine Validierungsausnahme Step Functions zurückgegeben.

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 setzentrue, 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). 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.

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 können Sie die rohe HTTP-Anfrage und -Antwort testen.

Testen eines Zustands mit AWS CLI

Sie können einen Status mithilfe der TestStateAPI 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:

Beispiel 1: Verwenden von INFO InspectionLevel zum Testen eines Choice-Status

Um einen Status mithilfe des INFO InspectionLevels 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 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 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 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, ParametersZustandsausgabe 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 mithilfe von TRACE InspectionLevel zusammen mit dem Parameter 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 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 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.

Alle Zustandstypen in der Sprache der Amazonas-Staaten (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,, Parameters ResultSelectorZustandsausgabe mithilfe von ResultPath In-Step-Funktionen angeben, und. Filtern der Statusausgabe mit OutputPath Die Support für jedes Feld ist von Bundesstaat zu Bundesstaat unterschiedlich. 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:

In der folgenden Liste wird die Reihenfolge beschrieben, in der die Eingabe- und Ausgabeverarbeitungsfelder im Diagramm angewendet 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 setzenDEBUG, enthält die API-Antwort ein aufgerufenes ObjektinspectionData. 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. afterInputPathZeigt beispielsweise, wie sich das Anwenden des InputPath Felds auf das Filtern der Rohstatuseingabe auswirkt. Das folgende Diagramm ordnet jedes ASL-Definitionsfeld dem entsprechenden Feld im inspectionData Objekt zu:

Beispiele für die Verwendung der TestState API zum Debuggen der Eingabe- und Ausgabeverarbeitung finden Sie im Folgenden:

Speziell für Map-Status enthält das inspectionData Objekt, wenn auf festgelegt inspectionLevel istDEBUG, 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.

Informationen zu den Inspektionsdaten des Kartenzustands

Wenn Sie einen Map-Status mit der inspectionLevel Einstellung auf testenDEBUG, enthält die TestState API-Antwort zusätzliche Felder im inspectionData Objekt, die zeigen, wie Ihr Map-Status Daten verarbeitet:

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

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:

Bei Wiederholungsblöcken können Sie Folgendes bestätigen:

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:

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:

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:

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.TaskFailedist 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 angegebenerrorCausedByState, 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:

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:

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.

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"}}'

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:

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\": {...}}"}'

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:

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": "..."}'

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:

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.

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:

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:

Sie können auch testen, was passiert, wenn alle Wiederholungsversuche durch Erhöhung der RetryCount Werte in Ihrem Kontextobjekt erschöpft sind.