Antigravity Agent
4.5 KiB
4.5 KiB
Mocking and Stubbing (테스트 대역)
📌 Brief Summary
Mocking과 Stubbing은 프로덕션 환경에서 사용하는 실제 객체를 테스트 목적에 맞게 구현된 가짜 객체로 대체하는 '테스트 대역(Test Doubles)'의 두 가지 다른 종류이다 [1]. 이는 실제 클래스, 모듈, 함수를 대신하여 테스트 시작 시 미리 정의된 응답(canned responses)을 반환하도록 설정된다 [2]. 이를 통해 개발자는 데이터베이스나 네트워크 통신과 같이 속도가 느리거나 부수 효과가 큰 의존성을 분리하고, 복잡한 테스트 설정을 피해 코드를 통제된 환경에서 완벽히 격리하여 테스트할 수 있다 [2, 3].
📖 Core Content
- 테스트 대역(Test Doubles)의 정의 및 역할: Mock과 Stub은 실제 컴포넌트와 동일한 서명(signature)을 가지면서도 테스트 시나리오에 맞춰 조작된 응답을 제공하는 가짜(fake) 버전의 컴포넌트이다 [2]. 단위 테스트뿐만 아니라 시스템의 특정 부분을 통제된 방식으로 시뮬레이션하기 위해 폭넓게 활용되며, 개발자는 Mockito나 Wiremock과 같은 서드파티 라이브러리를 통해 의존성을 손쉽게 Mocking하거나 외부 서비스를 Stubbing할 수 있다 [2, 4].
- 격리(Isolation)와 의존성 분리: 테스트를 작성할 때 외부 협력자(collaborator)로 인해 부수 효과가 발생하거나 설정이 복잡해지는 것을 막기 위해 테스트 대역을 사용한다 [3]. 특히 마이클 페더스(Michael Feathers)의 레거시 코드 리팩토링 전략에서는 테스트를 방해하는 무거운 외부 자원(DB, 네트워크 등)에 대한 직접적인 호출을 추상화하여, 테스트 시에 가짜 객체(Mock)를 주입할 수 있도록 '접점(Seams)'을 확보하는 것을 의존성 제거의 핵심으로 본다 [5, 6].
- 테스트의 단순화 및 예측 가능성 확보: Stubbing을 활용하면 테스트 데이터를 쉽게 설정할 수 있으며, 테스트가 훨씬 단순해지고 예측 가능해진다 [7]. 예를 들어, 서드파티 API(예: 날씨 정보 제공 서비스)와의 연동을 테스트할 때 실제 서버 대신 Fake 서버를 구축하여 테스트를 수행하면, 외부 서버의 할당량 제한이나 서버 점검 등의 가용성에 영향을 받지 않고 애플리케이션의 응답 파싱 능력을 독립적으로 검증할 수 있다 [8].
- LLM을 활용한 테스트 생성에서의 활용: AI를 활용한 테스트 스위트(Test Suite) 구축 사례에서도 요청 가로채기(request interception)를 기반으로 한 API Mocking 계층을 중앙 집중화하여 중복을 줄이고 테스트 인프라의 안정성을 높인 바 있다 [9].
⚖️ Trade-offs & Caveats
- 고립(Solitary) vs. 사교적(Sociable) 테스트의 트레이드오프: 모든 협력자를 Mock과 Stub으로 대체하여 완벽한 격리를 추구할 것인지(Solitary), 아니면 부수 효과가 큰 데이터베이스나 네트워크 호출 등 외곽 부분만 Stubbing하고 나머지 실제 협력자의 상호작용은 허용할 것인지(Sociable)에 대한 논쟁이 존재한다 [3]. 실제 객체와의 상호작용을 모두 Mocking하게 되면, 실제 협력자를 포함했을 때 얻을 수 있는 테스트의 통합적 신뢰성을 잃게 될 위험이 있다 [10].
- 가짜 객체(Test Double)의 신뢰성 한계 및 거짓 양성(False Positives): 외부 REST API 등을 Stubbing하여 가짜 서버(Fake server)를 만들 경우, 실제 외부 서비스의 API 스펙이 변경되더라도 가짜 서버를 바라보는 내부 테스트는 여전히 통과(Green)하는 취약점이 발생할 수 있다 [11]. 즉, 가짜 서버가 실제 서버의 동작을 완벽히 대변(faithful test double)하지 못할 위험이 있다 [11]. 이 제약을 극복하기 위해서는 가짜 서버와 실제 서버 모두에 대해 '계약 테스트(Contract Tests)'를 실행하여 Stub이 실제 스펙과 일치하는지 지속적으로 검증해야 한다 [11].
- AI 생성 테스트의 한계: 거대 언어 모델(LLM)을 활용하여 자동 생성된 테스트의 경우, 일반적인 기법에 비해 문장 및 분기 커버리지는 우수하지만 여전히 Mocking 기능이 불충분하거나 테스트 자체가 깨지기 쉬운(brittleness) 문제가 발생할 수 있다 [12]. 이러한 한계는 프롬프팅 전략의 개선 등을 통해 보완해야 한다 [12].
Last updated: 2026-05-03