翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Step Functions Local を使用したステートマシンのテスト (非サポート)
**Step Functions Local はサポートされていません**
Step Functions Local はクラウド版と同等の機能を**提供しておらず**、**サポートされていません**。
テスト目的で Step Functions をエミュレートするサードパーティーソリューションを検討することもできます。
Step Functions Local の代わりに、TestState API を使用して、 AWS アカウントにデプロイする前にステートマシンロジックをユニットテストできます。詳細については、[「TestState API を使用したステートマシン](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html)のテスト」を参照してください。
AWS Step Functions のダウンロード可能なバージョンである Step Functions Local を使用すると、独自の開発環境で実行されている Step Functions を使用してアプリケーションをテストできます。
Step Functions Local を実行している間は、次のいずれかの方法でサービス統合を呼び出すことができます。
+ AWS Lambda およびその他の サービスのローカルエンドポイントの設定。
+ Step Functions Local から AWS サービスを直接呼び出します。
+ サービス統合からのレスポンスをモックします。
AWS Step Functions Local は、Microsoft Windows、Linux、macOS、および Java または Docker をサポートする他のプラットフォームで実行される JAR パッケージまたは自己完結型 Docker イメージとして使用できます。
**警告**
Step Functions Local はテスト目的のみに使用し、機密情報の処理には決して使用しないでください。
**Topics**
+ [Step Functions Local と Docker のセットアップ](#sfn-local-docker)
+ [Step Functions Local のセットアップ - Java バージョン](#sfn-local-jar)
+ [Step Functions Local のオプションの設定](#sfn-local-config-options)
+ [Step Functions Local の実行](#sfn-local-computer)
+ [チュートリアル: Step Functions と CLI Local AWS SAM を使用したテスト](sfn-local-lambda.md)
+ [モックサービス統合を使用したテスト](sfn-local-test-sm-exec.md)
## Docker での Step Functions Local (ダウンロード可能バージョン) のセットアップ
Step Functions Local Docker イメージでは、Docker イメージを必要なすべての依存関係とともに使用して、Step Functions Local の使用をすぐにスタートできます。この Docker イメージでは、Step Functions Local を継続的統合テストの一部としてコンテナ化されたビルドに組み込むことができます。
Step Functions Local の Docker イメージを取得するには、[https://hub.docker.com/r/amazon/aws-stepfunctions-local](https://hub.docker.com/r/amazon/aws-stepfunctions-local) を参照するか、次の Docker `pull` コマンドを入力します。
```
docker pull amazon/aws-stepfunctions-local
```
ダウンロード可能なバージョンの Step Functions を Docker で起動するには、次の Docker `run` コマンドを実行します。
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
AWS Lambda または他のサポートされているサービスとやり取りするには、まず認証情報やその他の設定オプションを設定する必要があります。詳細については、以下の各トピックを参照してください。
+ [Step Functions Local の設定オプションを指定する](#sfn-local-config-options)
+ [Docker の認証情報と設定](#docker-credentials)
## Step Functions Local (ダウンロード可能バージョン) - Java バージョンのセットアップ
ダウンロード可能なバージョンの AWS Step Functions は、実行可能 JAR ファイルおよび Docker イメージとして提供されます。Java アプリケーションは、Windows、Linux、macOS、および Java をサポートする他のプラットフォームで動作します。Java に加えて、 AWS Command Line Interface () をインストールする必要がありますAWS CLI。のインストールと設定の詳細については AWS CLI、[AWS Command Line Interface 「 ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/)」を参照してください。
**コンピュータで Step Functions をセットアップして実行するには**
1. 次のリンクを使用して Step Functions をダウンロードします。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/sfn-local.html)
1. `.zip` ファイルを抽出します。
1. ダウンロードをテストし、バージョン情報を表示します。
```
$ java -jar StepFunctionsLocal.jar -v
Step Function Local
Version: 2.0.0
Build: 2024-05-18
```
1. (オプション) 使用可能なコマンドのリストを表示します。
```
$ java -jar StepFunctionsLocal.jar -h
```
1. コンピュータで Step Functions をスタートするには、コマンドプロンプトを開き、`StepFunctionsLocal.jar` を展開したディレクトリに移動して、次のコマンドを入力します。
```
java -jar StepFunctionsLocal.jar
```
1. ローカルで実行中の Step Functions にアクセスするには、`--endpoint-url` パラメータを使用します。たとえば、 を使用して AWS CLI、次のように Step Functions コマンドを指定します。
```
aws stepfunctions --endpoint-url http://localhost:8083 command
```
**注記**
デフォルトでは、Step Functions Local はローカルテストアカウントと認証情報を使用し、 AWS リージョンは米国東部 (バージニア北部) に設定されます。Step Functions Local を AWS Lambdaまたは他のサポートされているサービスで使用するには、認証情報とリージョンを設定する必要があります。
Express ワークフローを Step Functions Local で使用すると、実行履歴はログファイルに保存されます。これは CloudWatch ログには記録されません。ログファイルのパスは、ローカルステートマシンの作成時に指定された CloudWatch Logs ロググループ ARN に基づきます。ログファイルは、Step Functions Local を実行しているロケーションに相対的な `/aws/states/log-group-name/${execution_arn}.log` に保存されます。例えば、実行 ARN が以下であるとします。
```
arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI
```
ログファイルは以下のようになります。
```
aws/states/log-group-name/arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI.log
```
## Step Functions Local の設定オプションを指定する
JAR ファイルを使用して AWS Step Functions Local を起動する場合、 AWS Command Line Interface (AWS CLI) を使用するか、システム環境に含めて設定オプションを設定できます。Docker の場合、Step Functions Local を起動するときに、リファレンスにするファイルでこれらのオプションを指定する必要があります。
### 設定オプション
Lambda エンドポイントや Batch エンドポイントなどのオーバーライドエンドポイントを使用するよう Step Functions Local コンテナを設定して、そのエンドポイントを呼び出す場合、Step Functions Local では、指定した[認証情報](#docker-credentials)は使用されません。これらのエンドポイントオーバーライドの設定は任意です。
| オプション | コマンドライン | 環境 |
| --- | --- | --- |
| アカウント | -account, --aws-account | AWS\$1ACCOUNT\$1ID |
| リージョン | -region, --aws-region | AWS\$1DEFAULT\$1REGION |
| 待機タイムスケール | -waitTimeScale, --wait-time-scale | WAIT\$1TIME\$1SCALE |
| Lambda エンドポイント | -lambdaEndpoint, --lambda-endpoint | LAMBDA\$1ENDPOINT |
| バッチエンドポイント | -batchEndpoint, --batch-endpoint | BATCH\$1ENDPOINT |
| DynamoDB エンドポイント | -dynamoDBEndpoint, --dynamodb-endpoint | DYNAMODB\$1ENDPOINT |
| ECS エンドポイント | -ecsEndpoint, --ecs-endpoint | ECS\$1ENDPOINT |
| Glue エンドポイント | -glueEndpoint, --glue-endpoint | GLUE\$1ENDPOINT |
| SageMaker エンドポイント | -sageMakerEndpoint, --sagemaker-endpoint | SAGE\$1MAKER\$1ENDPOINT |
| SQS エンドポイント | -sqsEndpoint, --sqs-endpoint | SQS\$1ENDPOINT |
| SNS エンドポイント | -snsEndpoint, --sns-endpoint | SNS\$1ENDPOINT |
| Step Functions エンドポイント | -stepFunctionsEndpoint, --step-functions-endpoint | STEP\$1FUNCTIONS\$1ENDPOINT |
### Docker の認証情報と設定
Step Functions Local for Docker を設定するには、次のファイル `aws-stepfunctions-local-credentials.txt` を作成します。
このファイルには、認証情報および他の設定オプションが含まれています。`aws-stepfunctions-local-credentials.txt` ファイル作成時のテンプレートとして、以下を使用できます。
```
AWS_DEFAULT_REGION=AWS_REGION_OF_YOUR_AWS_RESOURCES
AWS_ACCESS_KEY_ID=YOUR_AWS_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_KEY
WAIT_TIME_SCALE=VALUE
LAMBDA_ENDPOINT=VALUE
BATCH_ENDPOINT=VALUE
DYNAMODB_ENDPOINT=VALUE
ECS_ENDPOINT=VALUE
GLUE_ENDPOINT=VALUE
SAGE_MAKER_ENDPOINT=VALUE
SQS_ENDPOINT=VALUE
SNS_ENDPOINT=VALUE
STEP_FUNCTIONS_ENDPOINT=VALUE
```
認証情報と設定オプションを `aws-stepfunctions-local-credentials.txt` で設定したら、次のコマンドを使用して Step Functions を起動します。
```
docker run -p 8083:8083 --env-file aws-stepfunctions-local-credentials.txt amazon/aws-stepfunctions-local
```
**注記**
ホストが使用する内部 IP アドレス (`http://host.docker.internal:8000` など) に対応する特別な DNS 名、`host.docker.internal` を使用することをお勧めします。詳細については、[Networking features in Docker Desktop for Mac](https://docs.docker.com/desktop/mac/networking/#use-cases-and-workaround) および [Networking features in Docker Desktop for Windows](https://docs.docker.com/desktop/windows/networking/) で、Mac 用と Windows 用の Docker ドキュメンテーションをそれぞれ参照してください。
## Step Functions Local を自分のコンピュータで実行する
ローカルバージョンの Step Functions を使用して、コンピュータでステートマシンを設定、開発、およびテストします。
### HelloWorld ステートマシンをローカルで実行する
AWS Command Line Interface (AWS CLI) を使用して Step Functions をローカルで実行した後、ステートマシンの実行を開始できます。
1. ステートマシン定義をエスケープ AWS CLI して、 からステートマシンを作成します。
```
aws stepfunctions --endpoint-url http://localhost:8083 create-state-machine --definition "{\
\"Comment\": \"A Hello World example of the Amazon States Language using a Pass state\",\
\"StartAt\": \"HelloWorld\",\
\"States\": {\
\"HelloWorld\": {\
\"Type\": \"Pass\",\
\"End\": true\
}\
}}" --name "HelloWorld" --role-arn "arn:aws:iam::012345678901:role/DummyRole"
```
**注記**
`role-arn` は Step Functions Local には使用されませんが、適切な構文に含める必要があります。前の例の Amazon リソースネーム (ARN) を使用できます。
ステートマシンを正常に作成すると、Step Functions は作成日とステートマシンの ARN で応答します。
```
{
"creationDate": 1548454198.202,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
1. 作成したステートマシンの ARN を使用して実行を開始します。
```
aws stepfunctions --endpoint-url http://localhost:8083 start-execution --state-machine-arn arn:aws:states:region:account-id:stateMachine:HelloWorld
```
### CLI Local AWS SAM を使用した Step Functions Local
ローカルバージョンの AWS Lambdaを、ローカルバージョンの Step Functions で使用できます。これを設定するには、 AWS SAMをインストールして設定する必要があります。
の設定と実行の詳細については AWS SAM、以下を参照してください。
+ [セットアップ AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
+ [CLI Local AWS SAM を起動する](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-start-lambda.html)
ローカルシステムで Lambda が実行されたら、Step Functions Local をスタートできます。Step Functions Local の JAR ファイルを展開したディレクトリから Step Functions Local を起動し、`--lambda-endpoint` パラメータを使用してローカルの Lambda エンドポイントを設定します。
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://127.0.0.1:3001 command
```
で Step Functions Local を実行する方法の詳細については AWS Lambda、「」を参照してください[チュートリアル: Step Functions と CLI Local AWS SAM を使用したワークフローのテスト](sfn-local-lambda.md)。
# チュートリアル: Step Functions と CLI Local AWS SAM を使用したワークフローのテスト
**Step Functions Local はサポートされていません**
Step Functions Local はクラウド版と同等の機能を**提供しておらず**、**サポートされていません**。
テスト目的で Step Functions をエミュレートするサードパーティーソリューションを検討することもできます。
Step Functions Local の代わりに、TestState API を使用して、 AWS アカウントにデプロイする前にステートマシンロジックをユニットテストできます。詳細については、[「TestState API を使用したステートマシン](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html)のテスト」を参照してください。
ローカルマシンで AWS Step Functions と の両方 AWS Lambda を実行すると、コードをデプロイせずにステートマシンと Lambda 関数をテストできます AWS。
詳細については、以下の各トピックを参照してください。
+ [Step Functions Local を使用したステートマシンのテスト (非サポート)](sfn-local.md)
+ [セットアップ AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
## ステップ 1: をセットアップする AWS SAM
AWS Serverless Application Model (AWS SAM) CLI Local では AWS Command Line Interface、、 AWS SAM、および Docker をインストールする必要があります。
1. [CLI AWS SAM をインストールします](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)。
**注記**
CLI AWS SAM をインストールする前に、 AWS CLI と Docker をインストールする必要があります。CLI AWS SAM をインストールするための[前提条件](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html)を参照してください。
1. [AWS SAM クイックスタート](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)ドキュメントをひととおり確認してください。必ず、以下のステップに従います。
1. [アプリケーションの初期化](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-setup-local-app)
1. [アプリケーションのローカルテスト](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-test-locally)
これにより、`sam-app` ディレクトリが作成され、Python ベースの Hello World Lambda 関数を含む環境が構築されます。
## ステップ 2: CLI Local AWS SAM をテストする
Hello World Lambda 関数をインストール AWS SAM して作成したので、関数をテストできます。`sam-app` ディレクトリで、次のコマンドを入力します。
```
sam local start-api
```
これにより、Lambda 関数のローカルインスタンスが起動されます。次のような出力が表示されます:
```
2019-01-31 16:40:27 Found credentials in shared credentials file: ~/.aws/credentials
2019-01-31 16:40:27 Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [GET]
2019-01-31 16:40:27 You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template
2019-01-31 16:40:27 * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)
```
ブラウザを開き、次のように入力します。
```
http://127.0.0.1:3000/hello
```
これにより、次のようなレスポンスが出力されます。
```
{"message": "hello world", "location": "72.21.198.66"}
```
**Ctrl\$1C** キーを押して、Lambda API を終了します。
## ステップ 3: CLI Local AWS SAM を起動する
関数が機能することをテストしたので、CLI Local AWS SAM を起動します。`sam-app` ディレクトリで、次のコマンドを入力します。
```
sam local start-lambda
```
これにより AWS SAM CLI Local が開始され、次の出力と同様に、使用するエンドポイントが提供されます。
```
2019-01-29 15:33:32 Found credentials in shared credentials file: ~/.aws/credentials
2019-01-29 15:33:32 Starting the Local Lambda Service. You can now invoke your Lambda Functions defined in your template through the endpoint.
2019-01-29 15:33:32 * Running on http://127.0.0.1:3001/ (Press CTRL+C to quit)
```
## ステップ 4: Step Functions Local のスタート
### JAR ファイル
Step Functions Local の `.jar` ファイルバージョンを使用している場合は、Lambda エンドポイントを指定して Step Functions をスタートします。`.jar` ファイルを展開したディレクトリで、次のコマンドを入力します。
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://localhost:3001
```
Step Functions Local がスタートすると、環境に続いて、`~/.aws/credentials` ファイルで設定した認証情報がチェックされます。デフォルトでは、架空のユーザー ID を使用して起動し、`region us-east-1` としてリスト表示されます。
```
2019-01-29 15:38:06.324: Failed to load credentials from environment because Unable to load AWS credentials from environment variables (AWS_ACCESS_KEY_ID (or AWS_ACCESS_KEY) and AWS_SECRET_KEY (or AWS_SECRET_ACCESS_KEY))
2019-01-29 15:38:06.326: Loaded credentials from profile: default
2019-01-29 15:38:06.326: Starting server on port 8083 with account account-id, region us-east-1
```
### Docker
Docker バージョンの Step Functions Local を使用している場合、次のコマンドを使用して Step Functions を起動します。
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Docker バージョンの Step Functions のインストールについては、[Docker での Step Functions Local (ダウンロード可能バージョン) のセットアップ](sfn-local.md#sfn-local-docker) を参照してください。
**注記**
または `.jar` ファイルから Step Functions を起動する場合は環境変数を設定することで、コマンドラインを通じて、エンドポイントを指定できます。Docker バージョンの場合は、エンドポイントと認証情報をテキストファイルに指定する必要があります。[Step Functions Local の設定オプションを指定する](sfn-local.md#sfn-local-config-options) を参照してください。
## ステップ 5: CLI AWS SAM ローカル関数を参照するステートマシンを作成する
Step Functions Local が実行されたら、[ステップ 1: をセットアップする AWS SAM](#install-sam) で初期化した `HelloWorldFunction` を参照するステートマシンを作成します。
```
aws stepfunctions --endpoint http://localhost:8083 create-state-machine --definition "{\
\"Comment\": \"A Hello World example of the Amazon States Language using an AWS Lambda Local function\",\
\"StartAt\": \"HelloWorld\",\
\"States\": {\
\"HelloWorld\": {\
\"Type\": \"Task\",\
\"Resource\": \"arn:aws:lambda:region:account-id:function:HelloWorldFunction\",\
\"End\": true\
}\
}\
}\" --name "HelloWorld" --role-arn "arn:aws:iam::012345678901:role/DummyRole"
```
これによりステートマシンが作成され、実行をスタートするために使用できる Amazon リソースネーム (ARN) が提供されます。
```
{
"creationDate": 1548805711.403,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
## ステップ 6: ローカルステートマシンの実行を開始する
ステートマシンを作成したら、実行を開始します。次の **aws stepfunctions** コマンドを使用するときは、エンドポイントとステートマシンの ARN を参照する必要があります。
```
aws stepfunctions --endpoint http://localhost:8083 start-execution --state-machine arn:aws:states:region:account-id:stateMachine:HelloWorld --name test
```
これにより、`HelloWorld` ステートマシンの `test` という実行が開始されます。
```
{
"startDate": 1548810641.52,
"executionArn": "arn:aws:states:region:account-id:execution:HelloWorld:test"
}
```
Step Functions がローカルで実行されたので、 を使用して操作できます AWS CLI。例えば、この実行に関する情報を取得するには、以下のコマンドを使用します。
```
aws stepfunctions --endpoint http://localhost:8083 describe-execution --execution-arn arn:aws:states:region:account-id:execution:HelloWorld:test
```
実行のために `describe-execution` を呼び出すと、次のような出力により、完全な詳細が提供されます。
```
{
"status": "SUCCEEDED",
"startDate": 1549056334.073,
"name": "test",
"executionArn": "arn:aws:states:region:account-id:execution:HelloWorld:test",
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld",
"stopDate": 1549056351.276,
"output": "{\"statusCode\": 200, \"body\": \"{\\\"message\\\": \\\"hello world\\\", \\\"location\\\": \\\"72.21.198.64\\\"}\"}",
"input": "{}"
}
```
# Step Functions Local でのテストにモックサービス統合を使用する
**Step Functions Local はサポートされていません**
Step Functions Local はクラウド版と同等の機能を**提供しておらず**、**サポートされていません**。
テスト目的で Step Functions をエミュレートするサードパーティーソリューションを検討することもできます。
Step Functions Local では、モックサービス統合を使用して、統合サービスを実際に呼び出さなくてもステートマシンの実行パスをテストできます。モックサービス統合を使用するようにステートマシンを設定するには、モック設定ファイルを作成します。このファイルでは、サービス統合に必要な出力をモックレスポンスとして定義し、モックレスポンスを使用して実行パスをシミュレートする実行をテストケースとして定義します。
Step Functions Local にモック設定ファイルを提供して、実際のサービス統合呼び出しを行う代わりに、テストケースで指定されたモックレスポンスを使用するステートマシンを実行して、サービス統合呼び出しをテストできます。
**注記**
モック設定ファイルでモックサービス統合レスポンスを指定しない場合、Step Functions Local は Step Functions Local の設定時に設定したエンドポイントを使用して AWS サービス統合を呼び出します。Step Functions Local のエンドポイントの設定については、「[Step Functions Local の設定オプションを指定する](sfn-local.md#sfn-local-config-options)」を参照してください。
このトピックでは、以下のリストに定義されているいくつかの概念を使用しています。
+ モックサービス統合 - 実際のサービス呼び出しを実行する代わりにモックレスポンスを使用するように設定された Task ステートを指します。
+ モックレスポンス - Task ステートが使用するように設定できるモックデータを指します。
+ テストケース - モックサービス統合を使用するように設定されたステートマシン実行を指します。
+ モック設定ファイル - JSON を含むモック設定ファイルを指します。JSON はモックサービス統合、モックレスポンス、テストケースを定義します。
## モックサービス統合の設定
Step Functions Local を使用して任意のサービス統合をモックできます。ただし、Step Functions Local はモックを実際の API と同じにすることを強制しません。モックされた Task がサービスエンドポイントを呼び出すことはありません。モックレスポンスを指定しない場合、Task はサービスエンドポイントを呼び出そうとします。また、Step Functions Local は、`.waitForTaskToken` を使用してタスクをモックすると、自動的にタスクトークンを生成します。
## ステップ 1: モック設定ファイルでモックサービス統合を指定する
Step Functions AWS SDK と最適化されたサービス統合は、Step Functions Local を使用してテストできます。以下のイメージは、[ステートマシンの定義] タブで定義されているステートマシンを示しています。
![\[モックサービス統合の例。\]](http://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/images/msi-graph.png)
そのためには、[モック設定のファイル構造](#mock-cfg-struct) で定義されているセクションを含むモック設定ファイルを作成する必要があります。
1. モックサービス統合を含むテストを設定するための `MockConfigFile.json` という名前のファイルを作成します。
次の例は、`LambdaState` と `SQSState` という名前の 2 つのステートが定義されているステートマシンを参照するモック設定ファイルを示しています。
------
#### [ Mock configuration file example ]
以下は、[Lambda 関数を呼び出して](connect-lambda.md) [Amazon SQS にメッセージを送信する](connect-sqs.md)レスポンスをモックする方法を示すモック設定ファイルの例です。この例では、[`LambdaSQSIntegration`](#mock-cfg-sm-sect) ステートマシンには、`HappyPath`、`RetryPath`、`HybridPath` という名前の 3 つのテストケースがあり、これらは `LambdaState` および`SQSState` という名前の `Task` ステートをモックします。これらのステートは `MockedLambdaSuccess`、`MockedSQSSuccess`、`MockedLambdaRetry` およびモックサービスのレスポンスを使用します。これらのモックサービスのレスポンスはファイルの `MockedResponses` セクションで定義されています。
```
{
"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!"
}
}
}
}
}
}
```
------
#### [ State machine definition ]
以下は、`LambdaState` および `SQSState` という名前の 2 つのサービス統合タスクステートを定義する `LambdaSQSIntegration` というステートマシン定義の例です。`LambdaState` には、`States.ALL` に基づく再試行ポリシーが含まれています。
```
{
"Comment":"This state machine is called: LambdaSQSIntegration",
"StartAt":"LambdaState",
"States":{
"LambdaState":{
"Type":"Task",
"Resource":"arn:aws:states:::lambda:invoke",
"Parameters":{
"Payload.$":"$",
"FunctionName":"HelloWorldFunction"
},
"Retry":[
{
"ErrorEquals":[
"States.ALL"
],
"IntervalSeconds":2,
"MaxAttempts":3,
"BackoffRate":2
}
],
"Next":"SQSState"
},
"SQSState":{
"Type":"Task",
"Resource":"arn:aws:states:::sqs:sendMessage",
"Parameters":{
"QueueUrl":"https://sqs.us-east-1.amazonaws.com/account-id/myQueue",
"MessageBody.$":"$"
},
"End": true
}
}
}
```
------
以下のテストケースのいずれかを使用して、モック設定ファイルで参照されている `LambdaSQSIntegration` ステートマシン定義を実行できます。
+ `HappyPath` - このテストでは、それぞれ `MockedLambdaSuccess` と `MockedSQSSuccess` を使用して `LambdaState` と `SQSState` の出力をモックします。
+ `LambdaState` は次の値を返します。
```
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
```
+ `SQSState` は次の値を返します。
```
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
```
+ `RetryPath` - このテストでは、それぞれ `MockedLambdaRetry` と `MockedSQSSuccess` を使用して `LambdaState` と `SQSState` の出力をモックします。また、`LambdaState` は 4 回再試行するように設定されています。これらの試行に対するモックレスポンスは `MockedLambdaRetry` ステートで定義され、インデックス化されます。
+ 最初の試行は、次の例に示すように、原因とエラーメッセージを含むタスク失敗で終了します。
```
"0":{
"Throw": {
"Error": "Lambda.ResourceNotReadyException",
"Cause": "Lambda resource is not ready."
}
}
```
+ 1 回目と 2 回目の再試行は、次の例に示すように、原因とエラーメッセージを含むタスク失敗で終了します。
```
"1-2":{
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
}
```
+ 3 回目の再試行は、モックされた Lambda レスポンスの Payload セクションからのステート結果を含むタスク成功で終了します。
```
"3":{
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
}
```
**注記**
再試行ポリシーが設定されているステートでは、Step Functions Local は成功レスポンスを受け取るまで、ポリシーに設定された再試行回数を使い果たします。つまり、モックの再試行を連続する試行回数で示し、成功レスポンスを返すまですべての再試行を実施する必要があります。
再試行「3」のように、特定の再試行に対してモックレスポンスを指定しないと、ステートマシンの実行は失敗します。
+ `HybridPath` - このテストは `LambdaState` の出力をモックします。`LambdaState` が正常に実行され、モックされたデータをレスポンスとして受信したら、`SQSState` は本番環境で指定されたリソースに対して実際のサービス呼び出しを実行します。
モックサービス統合を使用してテスト実行を開始する方法については、「[ステップ 3: モックサービス統合テストを実行する](#run-mocked-serv-integ-tests)」を参照してください。
1. モックレスポンスの構造が、統合サービス呼び出しを行うときに受け取る実際のサービスレスポンスの構造と一致していることを確認してください。モックレスポンスの構造要件については、「[モックサービス統合の設定](#mock-resp-struct-req)」を参照してください。
前述のモック設定ファイルの例では、`MockedLambdaSuccess` および `MockedLambdaRetry` で定義されたモック応答は、`HelloFromLambda` の呼び出しから返される実際の応答の構造に準拠しています。
**重要**
AWS サービスレスポンスの構造は、サービスによって異なる場合があります。Step Functions Local は、モックレスポンス構造が実際のサービスレスポンス構造に準拠しているかどうかを検証しません。テストする前に、モックレスポンスが実際のレスポンスと一致していることを確認する必要があります。サービスレスポンスの構造を確認するには、Step Functions を使用して実際のサービス呼び出しを実行するか、それらのサービスのドキュメントを参照してください。
## ステップ 2: Step Functions Local にモック設定ファイルを提供する
Step Functions Local には、次のいずれかの方法でモック設定ファイルを提供できます。
------
#### [ Docker ]
**注記**
Docker バージョンの Step Functions Local を使用している場合、環境変数のみを使用してモック設定ファイルを指定できます。また、サーバーの初回起動時に Step Functions Local コンテナにモック設定ファイルをマウントする必要があります。
Step Functions Local コンテナ内の任意のディレクトリにモック設定ファイルをマウントします。次に、コンテナ内のモック設定ファイルへのパスを含む `SFN_MOCK_CONFIG` という名前の環境変数を設定します。この方法では、環境変数にファイルパスと名前が含まれている限り、モック設定ファイルに任意の名前を付けることができます。
以下のコマンドは Docker イメージを開始する形式を示しています。
```
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 イメージを開始します。
```
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
```
------
#### [ JAR File ]
以下のいずれかの方法を使用してモック設定ファイルを Step Functions Local に提供します。
+ モック設定ファイルを `Step FunctionsLocal.jar` と同じディレクトリに置きます。この方法を使用するときは、モック設定ファイル `MockConfigFile.json` に名前を付ける必要があります。
+ Step Functions Local を実行しているセッションで、`SFN_MOCK_CONFIG` という名前の環境変数をモック設定ファイルのフルパスに設定します。この方法では、環境変数にそのファイルパスと名前が含まれている限り、モック設定ファイルに任意の名前を付けることができます。次の例では、`SFN_MOCK_CONFIG` 変数は `/home/workspace` ディレクトリにある `EnvSpecifiedMockConfig.json` という名前のモック設定ファイルを指すように設定されています。
```
export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
```
**注記**
Step Functions Local に環境変数 `SFN_MOCK_CONFIG` を指定しない場合、デフォルトでは、Step Functions Local を起動したディレクトリにある `MockConfigFile.json` という名前のモック設定ファイルを読み込もうとします。
モック設定ファイルを `Step FunctionsLocal.jar` と同じディレクトリに配置して環境変数 `SFN_MOCK_CONFIG` を設定すると、Step Functions Local は環境変数で指定されたファイルを読み取ります。
------
## ステップ 3: モックサービス統合テストを実行する
モック設定ファイルを作成して Step Functions Local に提供したら、モック設定ファイルに設定されたステートマシンをモックサービス統合を使用して実行します。次に API アクションを使用して実行結果を確認します。
1. [モック設定ファイル](#create-mock-config-file)内の前述の定義に基づいてステートマシンを作成します。
```
aws stepfunctions create-state-machine \
--endpoint http://localhost:8083 \
--definition "{\"Comment\":\"Thisstatemachineiscalled:LambdaSQSIntegration\",\"StartAt\":\"LambdaState\",\"States\":{\"LambdaState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::lambda:invoke\",\"Parameters\":{\"Payload.$\":\"$\",\"FunctionName\":\"arn:aws:lambda:region:account-id:function:HelloWorldFunction\"},\"Retry\":[{\"ErrorEquals\":[\"States.ALL\"],\"IntervalSeconds\":2,\"MaxAttempts\":3,\"BackoffRate\":2}],\"Next\":\"SQSState\"},\"SQSState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::sqs:sendMessage\",\"Parameters\":{\"QueueUrl\":\"https://sqs.us-east-1.amazonaws.com/account-id/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \
--name "LambdaSQSIntegration" --role-arn "arn:aws:iam::account-id:role/service-role/LambdaSQSIntegration"
```
1. モックサービス統合を使用してステートマシンを実行します。
モック設定ファイルを使用するには、モック設定ファイルに設定されているステートマシンで `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API 呼び出しを行います。これを行うには、`StartExecution` が使用するステートマシン ARN にサフィックス、`#test_name` を追加します。`test_name` はテストケースで、同じモック設定ファイルでステートマシン用に設定されます。
以下のコマンドは、`LambdaSQSIntegration` ステートマシンとモックコンフィグレーションを使用する例です。この例では、[ステップ 1: モック設定ファイルでモックサービス統合を指定する](#create-mock-config-file) で定義された `HappyPath` テストを使用して `LambdaSQSIntegration` ステートマシンが実行されます。`HappyPath` テストには、`LambdaState` ステートおよび `SQSState` ステートが `MockedLambdaSuccess` および `MockedSQSSuccess` のモックサービスのレスポンスを使用して行うモックサービス統合呼び出しを処理するための実行設定が含まれています。
```
aws stepfunctions start-execution \
--endpoint http://localhost:8083 \
--name executionWithHappyPathMockedServices \
--state-machine arn:aws:states:region:account-id:stateMachine:LambdaSQSIntegration#HappyPath
```
1. ステートマシンの実行レスポンスを表示します。
モックサービス統合テストを使用した `StartExecution` の呼び出しに対するレスポンスは、通常の `StartExecution` の呼び出しに対するレスポンスと同じであり、実行 ARN と開始日を返します。
以下は、モックサービス統合テストを使用した `StartExecution` の呼び出しに対するレスポンスの例です。
```
{
"startDate":"2022-01-28T15:03:16.981000-05:00",
"executionArn":"arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```
1. `[ListExecutions](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListExecutions.html)`、`[DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html)`、または `[GetExecutionHistory](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetExecutionHistory.html)` API の呼び出しを実行して、実行の結果を確認します。
```
aws stepfunctions get-execution-history \
--endpoint http://localhost:8083 \
--execution-arn arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices
```
次の例は、ステップ 2 で示したレスポンス例の実行 ARN を使用して `GetExecutionHistory` の呼び出しに対する応答の一部を示しています。この例では、`LambdaState` と `SQSState` の出力は、[モック設定ファイル](#create-mock-config-file)の `MockedLambdaSuccess` と `MockedSQSSuccess` で定義されているモックデータです。また、モックデータは、実際のサービス統合呼び出しを実行して返されるデータと同じ方法で使用されます。また、この例では、`LambdaState` からの出力が入力として `SQSState` に渡されます。
```
{
"events": [
...
{
"timestamp": "2021-12-02T19:39:48.988000+00:00",
"type": "TaskStateEntered",
"id": 2,
"previousEventId": 0,
"stateEnteredEventDetails": {
"name": "LambdaState",
"input": "{}",
"inputDetails": {
"truncated": false
}
}
},
...
{
"timestamp": "2021-11-25T23:39:10.587000+00:00",
"type": "LambdaFunctionSucceeded",
"id": 5,
"previousEventId": 4,
"lambdaFunctionSucceededEventDetails": {
"output": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}",
"outputDetails": {
"truncated": false
}
}
},
...
"timestamp": "2021-12-02T19:39:49.464000+00:00",
"type": "TaskStateEntered",
"id": 7,
"previousEventId": 6,
"stateEnteredEventDetails": {
"name": "SQSState",
"input": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}",
"inputDetails": {
"truncated": false
}
}
},
...
{
"timestamp": "2021-11-25T23:39:10.652000+00:00",
"type": "TaskSucceeded",
"id": 10,
"previousEventId": 9,
"taskSucceededEventDetails": {
"resourceType": "sqs",
"resource": "sendMessage",
"output": "{\"MD5OfMessageBody\":\"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51\",\"MessageId\":\"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51\"}",
"outputDetails": {
"truncated": false
}
}
},
...
]
}
```
## Step Functions でモックサービス統合を使用するための設定ファイル
**Step Functions Local はサポートされていません**
Step Functions Local はクラウド版と同等の機能を**提供しておらず**、**サポートされていません**。
テスト目的で Step Functions をエミュレートするサードパーティーソリューションを検討することもできます。
Step Functions Local の代わりに、TestState API を使用して、 AWS アカウントにデプロイする前にステートマシンロジックをユニットテストできます。詳細については、[「TestState API を使用したステートマシン](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html)のテスト」を参照してください。
モックサービス統合を使用するには、まずモック設定を含む `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](#mock-cfg-sm-sect)
+ [MockedResponses](#mock-cfg-mckd-resp-sect)
##### 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 は、ある実行から次の実行までの反復状態に対して異なるモックレスポンスを使用する可能性があります。
##### 戻る
`Return` は `MockedResponse` オブジェクトのフィールドとして表されます。Task ステートをモックした場合の成功結果を指定します。
以下は、Lambda 関数の [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) を呼び出すためのモックレスポンスを含む `Return` オブジェクトの例です。
```
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
```
##### Throw
`Throw` は `MockedResponse` オブジェクトのフィールドとして表されます。失敗したタスクの[エラー出力](concepts-error-handling.md)を指定します。`Throw` の値は、文字列値を持つ `Error` および `Cause` フィールドを含むオブジェクトである必要があります。`MockConfigFile.json` の `Error` フィールドに指定する文字列値は、ステートマシンの `Retry` および `Catch` セクションで処理されるエラーと一致する必要があります。
以下は、Lambda 関数の [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) を呼び出すためのモックレスポンスを含む `Throw` オブジェクトの例です。
```
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
```