“결제 기능 테스트를 해야 하는데, 아직 PG사 연동 개발이 끝나지 않았어요.”
“외부 API가 점검 중이라, 저희 기능 테스트를 진행할 수가 없네요.”
개발 및 테스트 과정에서 우리는 이처럼 다른 시스템에 ‘의존’하고 있어, 테스트가 중단되는 상황을 자주 마주합니다.
이런 문제를 해결하기 위해, 실제 객체 대신 ‘가짜 객체’를 만들어 테스트를 계속 진행할 수 있도록 돕는 기술이 바로 ‘테스트 더블(Test Double)’입니다.
이 글에서 다루는 것
- 테스트 더블의 개념과 중요성
- 대표적인 유형: Mock과 Stub의 차이점
- QA가 테스트 더블을 이해해야 하는 이유
‘테스트 더블(Test Double)’, 정확히 무엇인가요?
‘테스트 더블’은 영화 촬영 시, 위험한 장면을 실제 배우 대신 연기하는 ‘스턴트 더블(Stunt Double)’에서 유래한 용어입니다.
이처럼, 소프트웨어 테스트에서 실제 객체를 사용하기 어렵거나 불가능할 때, 그 실제 객체인 척 연기하는 ‘가짜 객체’를 통칭하여 ‘테스트 더블’ 또는 ‘테스트 대역’이라고 부릅니다.
왜 ‘테스트 더블’이 필요한가요?
‘테스트의 독립성’과 ‘속도’를 확보하기 위해서입니다.
- 독립적인 테스트 환경 구축:
- 아직 개발되지 않았거나, 접근이 불가능한 외부 시스템(예: PG사, 외부 API)이 있더라도, 이를 흉내 내는 가짜 객체를 만들어 테스트를 중단 없이 진행할 수 있습니다.
- 빠르고 안정적인 단위 테스트:
- 단위 테스트의 핵심은 ‘하나의 기능’만 고립시켜 순수하게 테스트하는 것입니다.
- 만약 테스트 대상이 데이터베이스나 네트워크에 의존한다면, 테스트는 느려지고 외부 환경의 문제로 실패할 수 있습니다.
- 이때, DB나 네트워크를 흉내 내는 테스트 더블을 사용하면, 오직 코드 로직 자체의 정확성만 빠르고 안정적으로 검증할 수 있습니다.
대표적인 테스트 더블: Mock과 Stub
‘테스트 더블’에는 여러 종류가 있지만, 실무에서 가장 많이 사용되는 것은 ‘Mock’과 ‘Stub’입니다. 둘은 비슷해 보이지만, 명확한 목적의 차이가 있습니다.
| 구분 | Stub (스텁) | Mock (목) |
| 주요 목적 | 상태 검증 (State Verification) | 행위 검증 (Behavior Verification) |
| 역할 | 미리 정해진 데이터를 반환하는 ‘배우’ | 특정 메서드가 호출되었는지 ‘기록하는 스파이’ |
| 핵심 질문 | “올바른 값을 돌려주었는가?” | “올바른 함수를 호출했는가?” |
1. Stub (스텁): 정해진 답변만 하는 배우
Stub은 테스트 중에 호출되었을 때, 미리 준비된 데이터를 그대로 반환하는 단순한 가짜 객체입니다.
- 언제 사용하나요?
- 테스트 대상이 외부로부터 특정 데이터를 ‘받아서’ 사용하는 경우에 주로 쓰입니다.
- 예시:
- ‘사용자 정보 조회’ 기능을 테스트하고 싶지만, 실제 사용자 DB에 접근하고 싶지는 않습니다.
- 이때,
getUser(1)이 호출되면 항상{ "name": "홍길동", "age": 30 }이라는 가짜 데이터를 반환하도록 Stub을 만듭니다. - 그리고 우리는 이 가짜 데이터를 받은 우리 시스템이 화면에 ‘홍길동’이라는 이름을 잘 표시하는지만 검증합니다. (상태 검증)
2. Mock (목): 모든 행동을 지켜보는 스파이
Mock은 호출되었을 때, 어떤 함수가, 몇 번, 어떤 인자와 함께 호출되었는지를 모두 기록하고, 테스트가 끝난 후 그 ‘행위’가 올바르게 일어났는지 검증할 수 있는 똑똑한 가짜 객체입니다.
- 언제 사용하나요?
- 테스트 대상이 외부에 특정 데이터를 ‘보내는’ 경우에 주로 쓰입니다.
- 예시:
- ‘회원가입’ 기능이 성공했을 때, 사용자에게 환영 이메일을 보내는지 테스트하고 싶지만, 실제로 이메일을 발송하고 싶지는 않습니다.
- 이때, 이메일 발송 시스템을 흉내 내는 Mock 객체를 만듭니다.
- 회원가입 테스트를 실행한 후, 우리는 Mock에게 물어봅니다. “혹시
sendEmail이라는 함수가, ‘홍길동@example.com’이라는 인자와 함께, 정확히 1번 호출되었니?” (행위 검증)
결론: 격리된 테스트 환경의 중요성
테스트 더블은 복잡하게 얽혀있는 현대 소프트웨어 환경에서, 내가 테스트하고 싶은 대상을 깔끔하게 분리하여 ‘고립된’ 테스트 환경을 만들어주는 핵심적인 기술입니다.
QA가 Mock과 Stub의 개념과 차이점을 이해하면, 개발자와 테스트 전략에 대해 더 깊이 있는 소통을 할 수 있습니다. 특히, 불안정한 통합 테스트나 E2E 테스트에 대한 의존도를 줄이고, 더 빠르고 안정적인 단위 테스트의 품질을 높이는 데 크게 기여할 수 있습니다.
부록: QA를 위한 미니 체크리스트 ✅
- 우리 팀의 단위 테스트는 외부 의존성을 제거하기 위해 테스트 더블을 잘 활용하고 있는가?
- 외부 API가 아직 개발 중일 때, Mock 서버를 구축하여 병렬적으로 테스트를 진행하고 있는가?
- Stub을 사용하여, 다양한 예외 케이스(예: 외부 API가 에러를 반환하는 경우)를 쉽게 시뮬레이션하고 있는가?
참고 자료 (References)
- Martin Fowler, “Mocks Aren’t Stubs” (마틴 파울러의 블로그 아티클)
- ISTQB (International Software Testing Qualifications Board) 공식 용어집