기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 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 및 최적화된 서비스 통합을 테스트할 수 있습니다. 다음 이미지에서는 상태 머신 정의 탭에 정의된 상태 머신을 보여줍니다.
이렇게 하려면 [모의 구성 파일 구조](#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."
}
```