답변.

외부 서비스와의 테스트 격리는 신뢰할 수 있는 자동화의 필수 조건입니다.

문제 역사: 초기 자동화 시스템은 외부 API와 DB에 대한 문제가 발생했고, 이들은 자주 접근할 수 없거나 예기치 않은 데이터를 반환했습니다. 테스트 격리가 없으면 자동화 테스트 결과를 재현할 수 없습니다: 깜박임, 외부 문제로 인한 실패, 임의의 오류.

문제:

외부 서비스는 종종 불안정합니다: 계약이 변경될 수 있으며, 데이터가 없거나 테스트가 부작용을 일으킬 수 있습니다.
예측 가능한 결과를 위해 외부 응답을 제어("고정")할 필요가 있습니다.
느린 응답과 로컬 또는 CI에서 시나리오를 재현할 수 없는 상황.

해결책:

외부 API의 응답을 시뮬레이션하는 로컬 스탭(mock)과 스텁(stub)을 사용합니다. WireMock (Java), httpmock (Python), MockServer, TestContainers가 인기가 있습니다.
인메모리 솔루션이나 각 테스트 전에 데이터를 초기화하고 다시 채울 수 있는 픽스처를 사용하여 DB를 에뮬레이션합니다.

테스트 데이터의 ID를 변수로 빼내어 테스트가 병렬로 실행되도록 합니다.

import requests
BASE_URL = "http://localhost:1080/api"
def test_order_creation():
    mock_response = {"orderId": 12345, "state": "created"}
    # 실제 테스트에서 응답은 모의 서버가 반환합니다.
    # 여기서 requests.post 호출 및 assert ...

주요 특징:

외부 의존성을 시뮬레이션하기 위한 모의 서버의 사용.
상태의 청결: 테스트 전후 데이터 클리어링(setup/teardown).
테스트 엔티티의 ID 격리.

함정 질문.

모든 실행에서 실제 서비스로 통합 테스트를 수행해야 하나요?

아니요. 정기적으로 목/mock과 스텁/stub을 사용할 수 있으며, 통합 테스트는 별도로 더 적게 실행합니다.

실제 외부 API로 테스트가 항상 더 신뢰할 수 있는 결과를 제공하나요?

아니요. 오히려 이들은 불안정할 수 있으며, 파트너 측의 변화로 인해 실패할 수 있습니다. 지속적인 플리커 테스트는 파이프라인의 품질을 저하시킵니다.

외부 서비스가 있는 병렬 자동 테스트를 위해 동일한 테스트 데이터를 사용할 수 있나요?

아니요. 이는 충돌, 경쟁 상태 및 불안정을 초래할 수 있습니다. ID와 상태는 테스트/스레드마다 고유해야 합니다.

일반적인 오류 및 안티 패턴

테스트 데이터의 클리어링이나 격리가 없음.
유닛 테스트라도 실제 API 사용.
불합리한 타임아웃 시간 단축으로 인한 잘못된 실패.
외부 API의 변화를 고려하지 않음(모든 테스트가 동시에 망가짐).

실제 사례

부정적인 케이스

회사는 속도를 위해 모든 자동 테스트를 실제 외부 API(결제 게이트웨이)에서 실행하기로 결정했습니다. 몇 번 테스트가 차단되었고, 한도 초과가 발생하여 접근 복구에 시간이 걸렸고, 데이터가 실제 보고서로 유출되었습니다.

장점:

실제 서비스와 빠르게 통합할 수 있습니다.

단점:

운영자의 변화가 테스트를 망가뜨리며, 시간과 비용이 낭비되었고, '실제' 서비스에 테스트 쓰레기가 생겼으며, 재현이 어려워졌습니다.

긍정적인 케이스

MockServer와 가상의 인메모리 DB를 설정했습니다. 각 테스트 전에 상태가 초기화되었고, 데이터는 고유했습니다. 실제 통합 테스트는 별도로 드물게 실행되었습니다.