Mock의 적용 범위

[haeyoon1]

1. Mock이 무엇인가요?

2. 단위 테스트 작성 시 어디까지 mock을 적용 해야 할까요?

   1. 모든 의존성(repository)을 mock 처리해야한다
   2. 외부 api는 mock 처리하되 repository는 실제 DB를 사용한다
   3. 기타

[koreaioi]

Mock은 "테스트 대상이 의존하는 객체를 가짜로 대체하는 것" 입니다.
이 덕분에, 테스트하려는 객체의 책임과 판단 로직에 집중할 수 있습니다.

여기서, 테스트 대상과 그 대상의 어떤 책임을 확인하고 싶은지가 중요하다고 생각합니다!
이를 통해, mock 적용 범위를 정할 수 있다고 생각합니다. 더불어, 내가 생각하는 객체(테스트 대상)의 역할과 책임이 무엇인가도 생각해봐야겠죠!

---

mock 적용

Service를 예시로,,,

class XXXService {
    
    private final XXXRepository repository;

    public Reservation reserved(parameters~ ){
           boolean isDuplicated = repository.existsDateIdAndTimeId();
           validateDuplicatedDateTime(isDuplicated );
    }
    
}

위 상황에서 Mock을 사용하지 않을 경우,, 서비스에서 중복검증을 수행한다는 걸 어떻게 테스트 코드로 작성할 수 있을까요!?
아마 실제 repository를 주입받거나, fakeRepository를 사용하는 방법이 있을 겁니다.
검증하고 싶은 대상은 중복 검증에 대한 예외처리인데, 테스트 대상이 아닌, Repository를 신경써야합니다.

Mock을 사용하여, repository.existsDateIdAndTimeId()에서 true가 반환한다는 설정을 해두기만 하면,
서비스가 실제로 중복 검증을 수행하는 지, 즉, 서비스가 정말 판단 로직에 대한 책임을 잘 수행하고 있는 지, 집중할 수 있습니다.

어떤 책임을 확인하고 싶은지

다음 예시처럼

class XXXService {
    
    private final XXXRepository repository;

    public Reservation reserved(parameters~ ){
           boolean isDuplicated = repository.existsDateIdAndTimeId();
           validateDuplicatedDateTime(isDuplicated );
    }
    
}

서비스의 책임이 "중복되는 날짜/시간이 있다면 예외를 발생한다" 일 때, 중요한 건, 비즈니스 요구사항에 어긋날 때, 예외를 적절히 던져주고 있냐입니다. 따라서 DB가 어떻게 동작하는 지는 서비스의 책임이 아니며, existsDateIdAndTimeId()가 true일 때, 예외를 잘 처리하느냐가 테스트 관심사인 것이죠.
따라서 책임 밖에 있는 DB가 어떻게 동작하는 지는 mock을 고려해볼 대상입니다.
여기서 고려해볼 대상이라는 건, 무조건 mock을 사용하기 보다는, mock, fake 같은 테스트 대역을 고려해볼 수 있다는 의미입니다!

[softmoca]

Mock은 테스트 대상이 의존하는 객체를 가짜 객체로 대체하는 것이라고 생각합니다.
Mock을 사용하는 이유는 테스트 대상이 직접 책임져야 하는 판단 로직에 집중하기 위해서입니다.

다만 Mock을 어디까지 적용할지는 단순히 “의존성이면 전부 Mock 처리한다”로 정하기보다,
테스트 대상이 무엇인지, 그리고 그 대상의 어떤 책임을 검증하고 싶은지를
기준으로 판단해야 한다고 생각합니다.

예를 들어 Service를 테스트한다고 했을 때,
Service의 책임이 “특정 조건에서 예외를 던지는 것”이라면,
테스트의 관심사는 실제 Repository가 DB에서 데이터를 잘 조회하는지가 아니라,
Repository가 어떤 결과를 줬을 때 Service가 올바른 판단을 하는지일 수 있습니다.
이런 경우에는 Repository를 Mock이나 Fake 같은 테스트 대역으로 대체하는 선택이 가능하다고 생각합니다.

하지만 반대로 Repository의 SQL, DB 매핑, 제약 조건, 트랜잭션까지 함께 검증하고 싶다면
실제 DB를 사용하는 테스트가 더 적절할 수 있습니다.
즉, Repository를 Mock 처리할지 실제 DB를 사용할지는,
“Repository는 의존성이니까 Mock”이라는 기준이 아니라,
이번 테스트에서 DB 동작까지 검증 대상에 포함할 것인가로 판단해야 한다고 생각합니다.

현재 제가 내린 결론은, 외부 시스템을 제외하고는 Mock 사용을 최대한 지양하는 편이 좋다는 것입니다.

여기서 말하는 외부 시스템은 외부 API, 결제 서버, 메일 서버, 푸시 알림, S3처럼
네트워크를 타거나 실제 호출 시 비용과 부작용이 발생할 수 있는 의존성을 의미합니다.
이런 의존성은 실제로 호출하면 테스트가 느려지고 불안정해질 수 있기 때문에
Mock이나 Fake 같은 테스트 대역을 사용하는 것이 적절하다고 생각합니다.

반면 애플리케이션 내부의 도메인 객체나 Repository까지 무조건 Mock 처리하는 것은 조심해야 한다고 느꼈습니다.
특히 Mock 기반 Service 단위 테스트는 “실제 유즈케이스가 끝까지 동작하는가”보다 “내가 예상한 구현 순서대로 메서드가 호출됐는가”를 검증하는 방향으로 흐르기 쉽습니다.

그 결과 테스트가 구현 방식에 강하게 묶이고,
내부 리팩터링만 했는데도 테스트가 깨질 수 있습니다.
즉, 리팩토링 내성이 약해지고, 신뢰도가 낮아지는 치명적인 단점을 가지고 가게된다고 생각합니다.

Mock 적용 범위를 정하는 기준

Mock 적용 범위는 먼저 아래 질문에서 출발해야 한다고 생각합니다.

내가 지금 테스트하려는 대상은 무엇인가?

그 대상의 어떤 책임을 검증하고 싶은가?

Service의 책임을 테스트하고 싶다면, Service가 외부 의존성의 결과를 바탕으로 올바른 판단을 하는지에 집중할 수 있습니다.

예를 들어 Service의 책임이 “특정 조건에서 예외를 던지는 것”이라면, 테스트의 관심사는 실제 Repository가 DB에서 데이터를 잘 조회하는지가 아니라, Repository가 어떤 결과를 줬을 때 Service가 올바른 판단을 하는지일 수 있습니다.

이런 경우에는 Repository를 Mock이나 Fake 같은 테스트 대역으로 대체하는 선택이 가능하다고 생각합니다.

반대로 Repository의 책임을 테스트하고 싶다면, SQL이 의도대로 실행되는지, DB 매핑이 올바른지, 제약 조건이 잘 동작하는지, 트랜잭션이 의도대로 묶이는지를 실제 DB와 함께 검증해야 할 수 있습니다.

즉, Repository를 Mock 처리할지 실제 DB를 사용할지는 “Repository는 의존성이니까 Mock”이라는 기준이 아니라, 이번 테스트에서 DB 동작까지 검증 대상에 포함할 것인가로 판단해야 한다고 생각합니다.

그래서 Mock은 “모든 의존성을 대체하기 위한 기본값”이라기보다, 테스트 관심사가 아닌 의존성을 통제하기 위한 선택지라고 생각합니다.

다만 제 기준에서는 외부 시스템을 제외하고는 Mock 사용을 최대한 보수적으로 가져가고 싶습니다.

Mock을 많이 사용하면 테스트가 빠르고 고립되기는 하지만, 실제 유즈케이스의 동작보다 내부 구현의 호출 방식에 묶이기 쉬워지기 때문입니다.

외부 시스템과 DB는 어떻게 볼 수 있을까?

제가 Mock 사용을 적극적으로 고려하는 대상은 외부 시스템, 특히 네트워크를 타야 하는 의존성입니다.

예를 들어 외부 API, 결제 서버, 메일 서버, 푸시 알림, S3 같은 의존성은 실제로 호출하면 테스트가 느려지고, 불안정해지고, 비용이나 부작용이 발생할 수 있습니다.

이런 경우에는 Mock이나 Fake를 사용해서 테스트 대상의 책임에만 집중하는 것이 적절하다고 생각합니다.

다만 DB는 조금 특수하다고 생각합니다.

DB도 넓게 보면 외부 리소스이지만, 애플리케이션의 핵심 상태를 저장하고 비즈니스 정합성을 보장하는 중요한 협력 대상입니다. 특히 현재 저희가 진행하는 미션들처럼 Repository, SQL, 트랜잭션, 제약 조건까지 학습하고 검증해야 하는 상황에서는 실제 DB를 사용하는 테스트가 더 신뢰도 있다고 느꼈습니다.

또 한 가지 고려할 점은 그 DB에 접근하는 주체가 누구인가라고 생각합니다.

만약 해당 DB를 오직 우리 서비스만 접근한다면, 애플리케이션 코드와 DB 제약 조건을 함께 설계하고 통제할 수 있습니다. 이 경우 테스트에서도 실제 DB를 사용해 우리 서비스의 유즈케이스가 끝까지 잘 동작하는지 확인하는 의미가 큽니다.

반대로 우리 서비스가 아닌 다른 시스템도 같은 DB에 접근한다면 이야기가 달라질 수 있습니다. 다른 서비스나 배치, 레거시 시스템이 같은 데이터를 수정한다면, 우리 애플리케이션 코드만으로 정합성을 보장하기 어렵습니다. 이때는 테스트에서도 단순히 Repository를 Mock 처리하기보다, DB 제약 조건, 트랜잭션, 동시성, 데이터 상태 변화까지 더 중요하게 봐야 할 수 있다고 생각합니다.

즉, DB는 단순히 “외부 시스템이니까 Mock”으로 보기보다, 우리 서비스의 상태 저장소인지, 여러 시스템이 공유하는 저장소인지, 정합성 검증이 필요한 대상인지를 함께 고려해야 한다고 생각합니다.

Mock을 과하게 사용했을 때의 문제

Mock을 과하게 사용하면 테스트가 실제 유즈케이스보다 구현 방식에 강하게 묶일 수 있다고 생각합니다.

특히 Mock 기반 Service 단위 테스트는 “실제 유즈케이스가 동작하는가”보다 “내가 예상한 구현 순서대로 메서드가 호출됐는가”를 검증하는 형태가 되기 쉽습니다.

예를 들어 Repository 호출 여부나 호출 순서를 지나치게 검증하면, 테스트는 사용자가 기대하는 기능의 결과보다 내부 구현 흐름에 더 강하게 의존하게 됩니다.

이 경우 실제 기능은 동일한데 내부 구현을 리팩터링했다는 이유만으로 테스트가 깨질 수 있습니다.

Repository 메서드 이름을 바꾸거나, 조회 방식을 바꾸거나, 호출 순서를 조정했을 때 사용자 관점에서는 아무 변화가 없는데 테스트가 실패할 수 있습니다.

그 결과 테스트가 구현 방식에 강하게 묶이고, 리팩터링 내성이 약해집니다.

또한 실제 객체들이 함께 동작했을 때 발생할 수 있는 문제를 놓칠 수 있어, 테스트 신뢰성도 떨어질 수 있다고 생각합니다.

그래서 저는 외부 시스템처럼 Mock의 이점이 분명한 경우가 아니라면, Mock 사용을 최대한 지양하는 편이 좋겠다고 판단했습니다.

현재 제가 생각하는 Mock 적용 기준

현재 저는 Mock 적용 기준을 이렇게 정리하고 있습니다.

대상	Mock 사용에 대한 생각
외부 API / 네트워크 의존성	Mock 또는 Fake 사용을 적극 고려
결제 / 메일 / 푸시 / S3 등 부작용 있는 의존성	Mock 사용이 적절
Repository	테스트 목적에 따라 선택하되, 실제 DB 기반 테스트를 우선 고려
DB	단순 외부 시스템으로 보기보다 정합성 검증 대상인지 고려
Domain 객체	Mock하지 않고 실제 객체 사용
Service 내부 협력 객체	외부 시스템이 아니라면 Mock 사용을 보수적으로 판단

핵심은 Repository나 DB를 무조건 Mock 처리하지 않는 것입니다.

Service의 판단 로직만 아주 좁게 검증하고 싶다면 Repository를 Mock으로 대체할 수는 있습니다.

하지만 실제 SQL, DB 매핑, 트랜잭션, 제약 조건, 동시성 상황까지 검증하고 싶다면 실제 DB를 사용하는 통합 테스트가 더 적절할 수 있습니다.

또한 Mock을 사용한 Service 단위 테스트가 실제 유즈케이스 검증보다 호출 순서 검증에 가까워지고 있다면, 그 테스트는 다시 점검해볼 필요가 있다고 생각합니다.

이번 레벨2 미션에서의 결론

이번 미션에서는 Mock 사용이 제한된 상황이기도 했고, 주요 기능이 대부분 예약 생성, 조회, 변경, 삭제처럼 도메인 규칙과 DB 상태 변화에 연결되어 있었습니다.

그래서 Repository를 모두 Mock 처리한 Service 단위 테스트를 억지로 만들기보다는, 아래 방향이 더 적절하다고 생각했습니다.

• 도메인 규칙은 도메인 단위 테스트로 검증한다.
• API 흐름, Repository, DB 연동, 트랜잭션(이번엔 고려 X)은 통합 테스트로 검증한다.
• 외부 API처럼 네트워크를 타거나 부작용이 큰 의존성은 Mock/Fake를 고려한다.
• DB는 우리 서비스만 접근하는지, 다른 시스템도 함께 접근하는지까지 고려한다.

결론적으로 Mock은 테스트를 빠르게 만들기 위한 기본 선택지가 아니라, 테스트 대상의 책임에 집중하기 위해 필요한 경우 선택하는 도구라고 생각합니다.

다만 현재 제 기준에서는, 외부 시스템처럼 Mock의 이점이 명확한 경우를 제외하고는 Mock 사용을 최대한 지양하는 편이 좋다고 판단했습니다.

특히 Mock 기반 Service 단위 테스트가 실제 유즈케이스의 동작이 아니라 내부 메서드 호출 방식만 검증하게 된다면, 테스트가 구현에 묶이고 리팩터링 내성이 약해지며 신뢰성도 떨어질 수 있다고 생각합니다.

따라서 Mock 적용 범위는 “모든 의존성을 Mock할 것인가?”로 정하기보다,

테스트 대상이 누구인지, 어떤 책임을 검증하고 싶은지, 그리고 실제 의존성을 포함했을 때 테스트 신뢰도가 더 높아지는지를 기준으로 결정하는 것이 좋다고 생각합니다.

[Uechann]

Mock이란 무엇일까?

Mock은 테스트 대상이 의존하는 객체를 흉내내는 가짜 객체입니다.
실제 객체처럼 호출할 수 있지만, 내부 동작은 우리가 미리 정의한 대로만 응답하게 됩니다.
테스트 더블이라는 큰 범주 안에 Mock, Stub, Fake, Spy, Dummy라는 것이 존재하고, 이를 통틀어서 Mock이라고 부릅니다.

Mock을 왜 사용할까?

1. 느린 테스트
   Mock을 사용하지 않는다면 DB 조회, 외부 API 호출 등은 시간이 많이 걸릴 가능성이 있어 테스트 수천 개를 돌리기 어려울 수 있다.

2. 불안정한 테스트
   외부 API에 의존하게 된다면 다운이 되거나 네트워크가 끊기 되면 테스트가 실패할 가능성이 생긴다.

3. 제현하기 어려운 상황
   예를 들어서 DB 커텍션이 끊긴 경우, API가 타임아웃된든 경우 등 예외 상황을 실제로 만들기 어려운 경우 Mock이 필요하다.

4. 테스트 격리의 어려움
   A를 테스트 하려고 하는데 B, C가 모두 같이 동작해야 한다면, 지금 테스트 하려고 한는 것이 A, B, C 중 어떤 것의 버그인지 알기가 어렵다.

단위 테스트 작성 시 어디까지 Mock을 적용해야 할까?

먼저 생각해볼 수 있는 부분은 단위 테스트가 경계를 어디까지 설정하고 있을까에 대한 부분입니다.
현재 테스트를 하고자 하는 단위에 대한 생각이 달라서 어디까지 Mock을 적용해야할까에 대한 이야기가 나오는거 같습니다.
그리고 이렇게 테스트의 단위가 다르고 Mock의 적용 범위에 대한 생각을 해본다면, 다음과 같은 트레이드오프가 존재하는거 같습니다.

• Mocking을 너무 많이한다면, 테스트가 빠르고, 예왜 상황 재현이 쉽고, 실패 원인 추적이 쉽지만 ,구현 세부 사항에 종속된 깨지기 쉬운 테스트가 되거나,
• Mocking을 너무 적게 하면, 실제 동작에 가까운 검증이 가능하고, 리팩토링에 강하지만, 테스트가 너무 느려지고, 테스트 간 격리가 어렵고, 외부 환경에 너무 의존하게 되어, 실패 원인이 여러 곳일 가능성이 높아서 디버깅이 어렵게 됩니다.

그럼 우리는 단위 테스트를 어디까지 Mock을 적용해야할까? 에 대한 질문에 답을 해보자면 다음과 같이 정리할 수 있을거 같습니다.

Mock 의존성의 성격으로 나눠본다.

• 외부 API → Mock
• 다른 도메인의 Service → Mock
• 같은 도메인의 객체, VO → 실제 객체

또한, 테스트를 통해 모든 것을 검증하려고 하지 않고, 테스트 피라미드로 역할들을 분담하는 것이 필요하다고 생각합니다.

즉, 단위 테스트, Repository 테스트, 통합 테스트, 엔드투엔드 테스트까지 각 테스트에 책임을 어떻게 지고 있을까에 대한 생각으로 테스트를 작성하는게 중요하다고 생각합니다.

결론은, “Mock을 어디까지 적용해야할까?” 라는 질문에 “지금이 테스트 코드의 책임이 무엇인가?”를 생각하며 본질적인 질문으로 접근하는 자세가 필요할거 같습니다.