코드가 API를 호출할 때 실제 API가 실패할 때까지 기다리지 않고 코드를 테스트할 방법이 필요합니다. 선택할 수 있는 5가지 종류의 대체 이미지가 있습니다. 사람들은 이름을 엄밀히 구분하지 않고 사용하므로 이 문서에서 사용하는 방식은 다음과 같습니다.
- 스텁: 미리 준비된 응답을 반환하는 HTTP 클라이언트 또는 SDK 호출에 대한 인프로세스 대체입니다. 빠르고 반복 가능하며 작성한 응답에 사용한 당신의 논리를 테스트합니다.
- Mock: 코드가 이를 어떻게 호출했는지도 기록하는 스텁이므로 테스트에서 해당 호출을 확인할 수 있습니다. 스텁까지 도달합니다.
- 가짜 서버: 앱이 실제 API 대신 HTTP를 통해 호출하는 작은 동작하는 서버(종종 메모리 내)입니다. HTTP 클라이언트를 테스트하지만 앱이 해당 URL을 가리키도록 설정해야 합니다.
- 에뮬레이터: 서비스 소유자가 일반적으로 게시하는 서비스의 로컬 버전으로, 지원하는 작업에 대한 실제 버전처럼 동작합니다. 오류 처리에 의존하기 전에 그것이 포함하는 제한 사항과 실패를 확인하세요.
- 가로채기 프록시: 앱과 API 간의 네트워크에 배치됩니다. 앱은 실제 URL을 호출하고 프록시는 요청을 그대로 통과시키거나 그중 일부에 사용자가 정의한 응답으로 응답합니다. 앱은 프록시를 통해 트래픽을 보내야 하며 HTTPS의 경우 프록시의 인증서를 신뢰해야 합니다.
API를 호출하는 코드를 테스트하는 방법
| Approach | 테스트하는 내용 | 필요한 사항 | 바로 그때 |
|---|---|---|---|
| 스텁 또는 모의 | 특정 응답에 대한 논리 | 사용자의 테스트 프레임워크 | 단위 테스트에서 비즈니스 논리, 구문 분석 및 오류 분기를 테스트합니다. |
| Fake 서버 | HTTP 클라이언트 및 serialization | 앱의 기본 URL 설정 또는 구성 스위치 | API가 아직 존재하지 않거나 UI 작업을 위해 안정적인 백엔드가 필요할 수 있습니다. |
| 에뮬레이터 | 지원되는 작업에 대한 실제 서비스와 가까운 동작 | 다른 엔드포인트 또는 연결 문자열 | 서비스의 소유자가 하나를 제공하면 오프라인에서 개발할 수 있습니다 |
| 테스트 계정을 사용하는 실제 API | 진짜배기 | 자격 증명, 할당량 및 금액 | 종단 간 기본 경로를 확인합니다. |
| 프록시 가로채기 | 실제 URL에서 실행 중인 사용자의 앱(SDK 재시도 및 응답 헤더 포함) | 프록시 설정 및 인증서 신뢰 | 앱을 변경하지 않고 오류, 제한 및 대기 시간을 테스트합니다. |
이 중 1개를 초과하여 필요합니다. 스텁은 단위 테스트를 빠르게 합니다. 프록시는 실제 API가 잘못 동작할 때 전체 앱이 수행하는 작업을 보여줍니다. 두 가지가 어떻게 함께 작동하는지에 대한 자세한 내용은 Dev Proxy와 단위 테스트를 참조하세요.
코딩 에이전트가 만드는 것
코딩 에이전트에게 앱이 API 오류를 처리하도록 하고 작동한다는 것을 표시하도록 요청하면 자동으로 스탠드인을 선택합니다. 어느 것인지 알아보기 위해 코딩 에이전트 3개(총 210회 실행)로 테스트를 실행했습니다. 작업에서는 "속도 제한을 적절하게 처리하고 제대로 작동함을 보여 달라", "실제 API 호출에 비용을 지출하지 않고 확인해 달라", "OpenAI 키 또는 인터넷 연결 없이 이를 실행해 달라"와 같은 구문을 사용했습니다.
- 작업 코드를 요청한 140개 실행 중 76%에서 에이전트는 fetch 스텁,
httpx.MockTransport, 또는 임시 HTTP 서버와 같은 실패를 수작업으로 구성했습니다. - GitHub, OpenAI 또는 날씨 API를 호출하는 앱에서 실행되는 105개 중 61개에서 에이전트는 기본 URL 또는 구성 스위치를 앱에 추가하여 가짜에 도달할 수 있도록 했습니다.
- 실제 API를 사용할 수 있고 프롬프트가 이를 배제하지 않는 75개의 실행에서 0은 실제 API URL에서 앱을 테스트했습니다.
스텁은 단위 테스트에 적합한 선택입니다. 격차는 그들이 빠뜨리는 것입니다. 에이전트의 스텁은 API가 보내는 것과 일치하지 않을 수 있는 에이전트가 예상한 오류를 반환합니다. 그리고 앱으로 가짜 선박에 접근할 수 있도록 스위치가 추가되었습니다.
에이전트의 테스트로 작업하는 방법
- 로직용 스텁을 유지하세요. 그들은 빠르며 에이전트가 쓴 브랜치를 테스트합니다.
- 실제 오류 형식을 요청합니다. 에이전트에 공급자의 문서화된 상태 코드, 헤더 및 본문 필드를 바탕으로 각 시뮬레이션 오류를 만들도록 요청합니다. 단순한 429 응답만으로는 앱이
retry-after내용을 읽는지, 또는 청구 오류와 속도 제한을 구분하는지를 테스트하지 않습니다. - 테스트용으로 검토 스위치가 추가되었습니다. 테스트가 가짜(mock) 대상에 접근할 수 있도록 에이전트가 기본 URL 설정만 추가하는 경우 프로덕션 코드에서 해당 설정을 사용할지 여부를 결정합니다.
- 시뮬레이션된 실패를 사용하여 실제 URL에서 앱을 한 번 실행합니다. 출시하기 전에 실행 중인 앱, 해당 SDK 및 해당 재시도 정책이 API 자체 오류를 어떻게 처리하는지 확인하세요. 에이전트의 오류 처리를 단계별로 검토하려면 코딩 에이전트가 작성한 오류 처리를 확인하는 방법을 참조하세요.
앱에서 사용해보기
Dev Proxy는 개발을 위한 가로채는 프록시입니다. 앱의 코드를 변경하지 않고 앱이 이미 호출하는 URL에 대해 정의한 응답을 반환합니다. 구성에서 MockResponsePlugin을 사용하도록 설정합니다, devproxyrc.json:
{
"$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/rc.schema.json",
"plugins": [
{
"name": "MockResponsePlugin",
"enabled": true,
"pluginPath": "~appFolder/plugins/DevProxy.Plugins.dll",
"configSection": "mocksPlugin"
}
],
"urlsToWatch": [
"https://api.contoso.com/*"
],
"mocksPlugin": {
"$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.schema.json",
"mocksFile": "mocks.json"
}
}
그런 다음 mocks.json에서 응답을 정의합니다. 이것은 예측 엔드포인트에 대해 503 헤더와 함께 Retry-After를 반환합니다:
{
"$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v3.3.1/mockresponseplugin.mocksfile.schema.json",
"mocks": [
{
"request": {
"url": "https://api.contoso.com/v1/forecast*",
"method": "GET"
},
"response": {
"statusCode": 503,
"headers": [
{
"name": "Retry-After",
"value": "10"
}
],
"body": {
"error": "Service unavailable"
}
}
}
]
}
개발자 프록시를 시작하고 평소와 같이 앱을 실행합니다.
devproxy --config-file devproxyrc.json
mock과 일치하지 않는 요청은 실제 API로 이동합니다. 아직 존재하지 않는 백 엔드가 필요한 경우 CrudApiPlugin은 메모리 내 데이터를 사용하여 CRUD API를 시뮬레이션합니다 . 매번이 아니라 일부 요청에 대해 임의로 실패하게 하려면 임의 오류로 내 앱 테스트를 참조하세요. 개발 프록시를 설치하려면 개발 프록시 설정을 참조하세요.
다음 단계
또한, 다음을 참조하세요.
GitHub에서 Microsoft와 공동 작업
이 콘텐츠의 원본은 GitHub에서 찾을 수 있으며, 여기서 문제와 끌어오기 요청을 만들고 검토할 수도 있습니다. 자세한 내용은 참여자 가이드를 참조하세요.
Dev Proxy