Step Functions Local でのテストにモックサービス統合を使用する

Step Functions Local では、モックサービス統合を使用して、統合サービスを実際に呼び出さなくてもステートマシンの実行パスをテストできます。モックサービス統合を使用するようにステートマシンを設定するには、モック設定ファイルを作成します。このファイルでは、サービス統合に必要な出力をモックレスポンスとして定義し、モックレスポンスを使用して実行パスをシミュレートする実行をテストケースとして定義します。

Step Functions Local にモック設定ファイルを提供して、実際のサービス統合呼び出しを行う代わりに、テストケースで指定されたモックレスポンスを使用するステートマシンを実行して、サービス統合呼び出しをテストできます。

このトピックでは、以下のリストに定義されているいくつかの概念を使用しています。

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

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

ステップ 1: モック設定ファイルでモックサービス統合を指定する

Step Functions Local を使用して、Step Functions AWS SDK と最適化されたサービス統合をテストできます。以下のイメージは、[ステートマシンの定義] タブで定義されているステートマシンを示しています。

そのためには、モック設定のファイル構造 で定義されているセクションを含むモック設定ファイルを作成する必要があります。

ステップ 2: Step Functions Local にモック設定ファイルを提供する

Step Functions Local には、次のいずれかの方法でモック設定ファイルを提供できます。

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

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

ステップ 3: モックサービス統合テストを実行する

モック設定ファイルを作成して Step Functions Local に提供したら、モック設定ファイルに設定されたステートマシンをモックサービス統合を使用して実行します。次に API アクションを使用して実行結果を確認します。

Step Functions でモックサービス統合を使用するための設定ファイル

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

モック設定のファイル構造

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

以下は、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": {
      ...
    }
  }
}

戻る

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

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

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

Throw

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

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

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