モックサービス統合の設定ファイル - AWS Step Functions

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

モックサービス統合の設定ファイル

モックサービス統合を使用するには、まずモック設定を含む MockConfigFile.json という名前のモック設定ファイルを作成する必要があります。次に、Step Functions Local にモック設定ファイルを提供します。この設定ファイルは、モックサービス統合レスポンスを使用するモックステートを含むテストケースを定義します。以下のセクションには、モックステートとモックレスポンスを含むモック設定の構造に関する情報が含まれています。

モック設定の構造の紹介

モック設定は、次の最上位のフィールドを含む JSON オブジェクトです。

  • StateMachines - このオブジェクトのフィールドは、モックサービス統合を使用するように設定されたステートマシンを表します。

  • MockedResponse - このオブジェクトのフィールドは、サービス統合呼び出しのモックレスポンスを表します。

以下は、StateMachine 定義と 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!" } } } } } }

モック設定フィールドリファレンス

以下のセクションでは、モック設定で定義する必要がある最上位のオブジェクトフィールドについて説明します。

StateMachines

StateMachines オブジェクトは、どのステートマシンがモックサービス統合を使用するかを定義します。各ステートマシンの設定は、StateMachines の最上位フィールドとして表されます。フィールド名はステートマシンの名前で、値は TestCases という名前の 1 つのフィールドを含むオブジェクトです。そのフィールドはそのステートマシンのテストケースを表します。

次の構文は、2 つのテストケースを含むステートマシンを示しています。

"MyStateMachine": { "TestCases": { "HappyPath": { ... }, "SadPath": { ... } }
TestCases

TestCases のフィールドはステートマシンの個々のテストケースを表します。各テストケースの名前はステートマシンにつき一意である必要があり、各テストケースの値はステートマシンの Task 状態に使用するモックレスポンスを指定するオブジェクトです。

次の TestCase の例は、2 つの Task 状態を 2 つの MockedResponses にリンクしています。

"HappyPath": { "SomeTaskState": "SomeMockedResponse", "AnotherTaskState": "AnotherMockedResponse" }

MockedResponses

MockedResponses は、一意のフィールド名を持つ複数のモックレスポンスオブジェクトを含むオブジェクトです。モックレスポンスオブジェクトは、モックされた Task 状態が呼び出されるたびに、成功結果またはエラー出力を定義します。呼び出し番号は、「0」、「1」、「2」、「3」などの個別の整数文字列、または「0-1」、「2-3」などの整数の範囲を使用して指定します。

Task をモックする場合、呼び出しのたびにモックレスポンスを指定する必要があります。レスポンスには、Return または Throw という名前のフィールドが 1 つ含まれている必要があります。このフィールドの値は、モックされた Task 呼び出しの結果またはエラー出力です。モックレスポンスを指定しない場合、ステートマシンの実行は失敗します。

以下は、Throw および Return オブジェクトを含む MockedResponse の例です。この例では、ステートマシンを最初の 3 回実行すると、"0-2" で指定されたレスポンスが返され、4 回目にステートマシンが実行されると、"3" で指定されたレスポンスが返されます。

"SomeMockedResponse": { "0-2": { "Throw": { ... } }, "3": { "Return": { ... } } }
注記

Map ステートを使用していて、その Map ステートに対するレスポンスを予測できるようにする場合は、maxConcurrency の値を 1 に設定します。1 より大きい値を設定すると、Step Functions Local は複数の反復を同時に実行するため、反復にわたるステートの全体的な実行順序が予測できなくなります。これにより、Step Functions Local は、ある実行から次の実行までの反復状態に対して異なるモックレスポンスを使用する可能性があります。

戻る

ReturnMockedResponse オブジェクトのフィールドとして表されます。Task ステートをモックした場合の成功結果を指定します。

以下は、Lambda 関数の Invoke を呼び出すためのモックレスポンスを含む Return オブジェクトの例です。

"Return": { "StatusCode": 200, "Payload": { "StatusCode": 200, "body": "Hello from Lambda!" } }
Throw

ThrowMockedResponse オブジェクトのフィールドとして表されます。失敗したタスクのエラー出力を指定します。Throw の値は、文字列値を持つ Error および Cause フィールドを含むオブジェクトである必要があります。MockConfigFile.jsonError フィールドに指定する文字列値は、ステートマシンの Retry および Catch セクションで処理されるエラーと一致する必要があります。

以下は、Lambda 関数の Invoke を呼び出すためのモックレスポンスを含む Throw オブジェクトの例です。

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

モックサービス統合の設定

Step Functions Local を使用して任意のサービス統合をモックできます。ただし、Step Functions Local はモックを実際の API と同じにすることを強制しません。モックされた Task がサービスエンドポイントを呼び出すことはありません。モックレスポンスを指定しない場合、Task はサービスエンドポイントを呼び出そうとします。また、Step Functions Local は、.waitForTaskToken を使用してタスクをモックすると、自動的にタスクトークンを生成します。