테스트Medium#242
Mocking은 언제 유용하고 언제 위험할 수 있나요?
#테스트#Mock#TestDouble#의존성
답변 포인트
외부 의존성 대체와 과도한 격리를 기준으로 정의, 장점, 한계, 예시를 함께 설명해보세요.
정답 및 해설
빠른 요약
Mocking은 외부 API, DB, 시간 같은 의존성을 통제할 때 유용합니다. 하지만 구현 세부사항을 과도하게 mock하면 실제 통합 문제를 놓치고 리팩터링에 취약해집니다.
Mocking은 테스트 대상이 의존하는 외부 객체나 시스템을 가짜로 대체하는 기법입니다. 빠르고 결정적인 테스트를 만들 수 있지만, 과하면 실제 동작과 멀어진 “거짓 안정감”을 줍니다.
유용한 경우
- 결제 API, 이메일 발송처럼 실제 호출하면 비용이나 부작용이 있는 경우
- 네트워크 지연/오류를 재현해야 하는 경우
- 현재 테스트의 관심사가 의존 객체가 아니라 비즈니스 분기일 때
TypeScript
paymentClient.charge = vi.fn().mockResolvedValue({ status: 'approved' });
await orderService.pay(orderId);
expect(paymentClient.charge).toHaveBeenCalledWith(expect.any(Object));위험한 경우
내부 구현을 너무 자세히 mock하면 리팩터링 때 테스트가 쉽게 깨집니다. 또한 DB repository를 모두 mock하면 실제 쿼리, transaction, constraint 문제를 놓칩니다.
Text
나쁜 신호: 테스트가 “결과”보다 “몇 번 어떤 private 메서드를 호출했는지”에 집착함좋은 기준
- 외부 경계는 mock/fake로 제어합니다.
- 핵심 도메인 로직은 실제 객체로 테스트합니다.
- 중요한 integration path는 별도 통합 테스트로 보완합니다.
- mock은 성공뿐 아니라 timeout, 500, 잘못된 응답도 시뮬레이션합니다.
면접 답변 포인트
Mocking은 테스트를 빠르고 안정적으로 만들지만 실제 시스템과의 계약을 숨길 수 있습니다. 외부 경계에 제한적으로 쓰고, 중요한 연동은 통합/contract 테스트로 보완한다고 답하면 좋습니다.