기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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은 JAR 패키지 또는 Microsoft Windows, Linux, macOS 및 Java 또는 Docker를 지원하는 기타 플랫폼에서 실행되는 독립형 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 및 AWS SAM CLI Local을 사용한 테스트](sfn-local-lambda.md)
+ [모의 서비스 통합을 사용한 테스트](sfn-local-test-sm-exec.md)
## Docker에서 Step Functions Local(다운로드 가능 버전) 설정
Step Functions Local 도커 이미지를 사용하면 필요한 모든 종속성과 함께 도커 이미지를 사용하여 Step Functions Local을 빠르게 시작할 수 있습니다. 도커 이미지를 사용하면 Step Functions Local을 컨테이너화된 빌드에 지속적 통합 테스트의 일부로 포함할 수 있습니다.
Step Functions Local에 대한 도커 이미지를 가져오려면 [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
```
Docker에서 Step Functions의 다운로드 가능 버전을 시작하려면 다음 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 파일 및 도커 이미지로 제공됩니다. Java 애플리케이션은 Windows, Linux, macOS 및 Java를 지원하는 기타 플랫폼에서 실행됩니다. Java 외에도 AWS Command Line Interface ()를 설치해야 합니다AWS CLI. 설치 및 구성에 대한 자세한 내용은 [AWS Command Line Interface 사용 설명서를](https://docs.aws.amazon.com/cli/latest/userguide/) AWS CLI참조하세요.
**컴퓨터에 Step Functions를 설정하고 실행하기**
1. 다음 링크를 사용하여 Step Functions를 다운로드합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/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` 파라미터를 사용합니다. 예를 들어를 사용하여 Step Functions 명령을 다음과 같이 AWS CLI지정합니다.
```
aws stepfunctions --endpoint-url http://localhost:8083 command
```
**참고**
기본적으로 Step Functions Local은 로컬 테스트 계정과 보안 인증 정보를 사용하며 AWS 리전은 미국 동부(버지니아 북부)로 설정됩니다. AWS Lambda또는 기타 지원되는 서비스와 함께 Step Functions Local을 사용하려면 자격 증명 및 리전을 구성해야 합니다.
Step Functions Local에서 Express 워크플로를 사용하면 실행 내역이 로그 파일에 저장됩니다. CloudWatch Logs에는 로깅되지 않습니다. 로그 파일 경로는 로컬 상태 머신을 만들 때 제공된 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 엔드포인트 및 배치 엔드포인트와 같은 재정의 엔드포인트를 사용하도록 Step Functions Local 컨테이너를 구성하고 해당 엔드포인트를 직접적으로 호출하면 Step Functions Local에서 지정된 [보안 인증 정보](#docker-credentials)를 사용하지 않습니다. 이러한 엔드포인트 재정의 설정은 선택 사항입니다.
| 옵션 | 명령줄 | 환경 |
| --- | --- | --- |
| Account | -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에 대한 보안 인증 정보 및 구성
Docker용 Step Functions Local을 구성하려면 `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`을 사용하는 것이 좋습니다. 자세한 내용은 [Mac용 Docker Desktop의 네트워킹 기능](https://docs.docker.com/desktop/mac/networking/#use-cases-and-workaround) 및 [Windows용 Docker Desktop의 네트워킹 기능](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
```
### AWS SAM CLI Local을 사용한 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)
+ [AWS SAM CLI Local 시작](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 로컬 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 및 AWS SAM CLI Local을 사용하여 워크플로 테스트](sfn-local-lambda.md).
# 자습서: Step Functions 및 AWS SAM CLI 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 및를 모두 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. [AWS SAM CLI를 설치합니다](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html).
**참고**
AWS SAM CLI를 설치하기 전에 AWS CLI 및 Docker를 설치해야 합니다. AWS SAM CLI 설치를 위한 [사전 조건을 참조하세요](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단계: AWS SAM CLI Local 테스트
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단계: AWS SAM CLI Local 시작
이제 함수가 작동하는지 테스트했으므로 AWS SAM CLI Local을 시작합니다. `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 Funtions Local의 `.jar` 파일 버전을 사용하는 경우 Step Functions를 시작하고 Lambda 엔드포인트를 지정합니다. `.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
Step Functions Local의 Docker 버전을 사용하는 경우 다음 명령으로 Step Functions를 시작합니다.
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Step Functions의 Docker 버전 설치 방법은 [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단계: AWS SAM CLI 로컬 함수를 참조하는 상태 시스템 생성
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가 로컬에서 실행되므로를 사용하여 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이 포함된 모의 구성 파일을 나타냅니다.
## 모의 서비스 통합 구성
Step Functions Local을 사용하여 모든 서비스 통합을 모의할 수 있습니다. 하지만 Step Functions Local은 모의를 실제 API와 동일하게 적용하지 않습니다. 모의 Task는 서비스 엔드포인트를 직접적으로 호출하지 않습니다. 모의 응답을 지정하지 않으면 Task는 서비스 엔드포인트를 직접적으로 호출하려고 시도합니다. 또한 Step Functions Local은 `.waitForTaskToken`을 사용하여 Task를 모의할 때 자동으로 작업 토큰을 생성합니다.
## 1단계: 모의 구성 파일에 모의 서비스 통합 지정
Step Functions Local을 사용하여 Step Functions AWS SDK 및 최적화된 서비스 통합을 테스트할 수 있습니다. 다음 이미지에서는 상태 머신 정의 탭에 정의된 상태 머신을 보여줍니다.
![\[모의 서비스 통합 예제입니다.\]](http://docs.aws.amazon.com/ko_kr/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) 상태 머신에는 `LambdaState` 및 `SQSState`라는 `Task` 상태를 모의하는 `HappyPath`, `RetryPath` 및 `HybridPath`라는 테스트 사례 3개가 포함되어 있습니다. 이러한 상태는 `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 ]
다음은 `LambdaSQSIntegration`이라는 상태 머신 정의의 예제입니다. 이 정의에서 `LambdaState` 및 `SQSState`라는 서비스 통합 태스크 상태 2개를 정의합니다. `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":{
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
}
```
+ 세 번째 재시도는 모의 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 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
```
------
#### [ 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` 상태 머신과 모의 구성을 사용하는 예제입니다. 이 예시에서 `LambdaSQSIntegration` 상태 머신은 [1단계: 모의 구성 파일에 모의 서비스 통합 지정](#create-mock-config-file)에 정의된 `HappyPath` 테스트를 통해 실행됩니다. `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` 직접 호출에 대한 응답은 보통 실행 ARN과 시작 날짜를 반환하는 `StartExecution` 직접 호출에 대한 응답과 동일합니다.
다음은 모의 서비스 통합 테스트를 사용한 `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`라는 단일 필드가 포함된 객체입니다. 이 필드는 해당 상태 머신의 테스트 사례를 나타냅니다.
다음 구문에서는 테스트 사례가 2개 있는 상태 머신을 보여줍니다.
```
"MyStateMachine": {
"TestCases": {
"HappyPath": {
...
},
"SadPath": {
...
}
}
```
##### TestCases
`TestCases`의 필드는 상태 머신의 개별 테스트 사례를 나타냅니다. 각 테스트 사례 이름은 상태 머신마다 고유해야 하며 각 테스트 사례 값은 상태 머신의 Task 상태에 사용할 모의 응답을 지정하는 객체입니다.
다음 `TestCase` 예제에서는 두 `Task` 상태를 `MockedResponses` 2개에 연결합니다.
```
"HappyPath": {
"SomeTaskState": "SomeMockedResponse",
"AnotherTaskState": "AnotherMockedResponse"
}
```
##### MockedResponses
`MockedResponses`는 고유한 필드 이름을 가진 모의 응답 객체가 여러 개 포함된 객체입니다. 모의 응답 객체는 모의 Task 상태를 간접적으로 호출할 때마다 성공한 결과나 오류 출력을 정의합니다. “0”, “1”, “2” 및 “3”과 같은 개별 정수 문자열이나 “0-1”, “2-3"과 같은 포괄적인 정수 범위를 사용하여 간접 호출 번호를 지정합니다.
Task를 모의할 때 모든 간접 호출에 모의 응답을 지정해야 합니다. 응답에는 값이 모의 Task 간접 호출에 대한 결과나 오류 출력인 `Return` 또는 `Throw`라는 단일 필드가 포함되어야 합니다. 모의 응답을 지정하지 않으면 상태 머신 실행이 실패합니다.
다음은 `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` 객체 필드로 표시됩니다. 실패한 Task의 [오류 출력](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."
}
```