그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Architecture
Architecture

테스트 더블에 대해서 설명해주세요.

실무4/5
설계4/5
인간4/5
기초2/5

면접관의 질문 의도

용어를 외운 사람과 _어떤 더블을 언제 쓰는지_ 기준을 가진 사람을 가르는 질문이다. 종류 나열로 끝내면 후속에서 상태 검증과 행위 검증의 차이로 곧장 들어간다.

큐레이션 답변

학습 자료

테스트 더블은 실제 의존성 대신 사용하는 대체 객체를 통틀어 부르는 말이다. Meszaros 분류로 더미·스텁·페이크·스파이·목 다섯 종류가 있는데, 단순히 자리만 채우는지(더미), 정해진 값을 돌려주는지(스텁), 동작하는 가짜 구현인지(페이크), 호출을 기록만 하는지(스파이), 호출 자체를 검증 대상으로 두는지(목)로 갈린다. 핵심은 _상태를 검증_할지 _상호작용을 검증_할지에 따라 더블 종류가 정해진다는 점이다.

좋은 답변 구조

  1. 01테스트 더블이 왜 등장했는지 정의와 함께 정리한다
  2. 02더미·스텁·페이크·스파이·목 다섯 종류를 무엇을 대신하는가로 구분한다
  3. 03상태 검증과 행위 검증을 기준으로 더블 선택 기준을 설명한다
  4. 04목 남용·페이크 과신 같은 흔한 함정을 짚는다

자주 실수하는 포인트

스텁이면 충분한 자리에 목을 써서 호출 검증 과잉으로 만든다
상태 검증과 행위 검증을 한 테스트 안에 섞어 무엇이 깨졌는지 못 본다
페이크를 가짜 구현이 아니라 실제 대체품으로 다뤄 프로덕션 코드처럼 신뢰한다

실무 맥락

  • 느린 외부 API나 결제 게이트웨이에 의존하는 단위 테스트를 끊어야 하는 환경
  • DB 부팅 없이 비즈니스 로직 단위 테스트를 빠르게 돌려야 하는 환경
  • 메일 발송·로그 적재 같은 사이드이펙트를 검증해야 하지만 실제로 일으키면 곤란한 환경

본인 경험에 녹이는 힌트

목을 남용해서 리팩토링할 때마다 테스트가 깨졌던 경험이 있다면 행위 검증의 비용 이야기로 이어갈 수 있다

외부 API 의존 테스트가 느려서 더블로 갈아 끼웠던 경험을 결정적 테스트 만들기 사례로 풀 수 있다

팀 안에서 스텁과 목 선택 기준을 정리해본 적이 있다면 의도 기반 테스트 설계로 연결할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1스텁과 목의 핵심 차이를 검증 방식 관점에서 설명해주세요
Q2목을 과하게 쓰면 어떤 문제가 생기고 그 신호는 어떻게 알아채나요
Q3페이크가 실제 구현과 어긋나면 어떤 위험이 있고 어떻게 줄이나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문