Mock 객체 어디까지 사용해야 할까? (feat. Top-Down TDD)

[jaejae-yoo]

OAuth를 사용한 로그인 기능은 외부 API와 연동되는 기능이기 때문에 테스트하기 까다로웠는데요.
해당 문제를 적절히 모킹 객체를 사용하면서, 잘 해결해 나아갈 수 있었던 것 같습니다.

Mock 객체를 사용하는 기준이 있는지 궁금해서 discussion 올립니다! 🤓

---

예시 코드를 보며 정리해 보겠습니다.

@SpringBootTest
class AuthServiceTest {

    private MemberRepository memberRepository;
    private OAuthClient oAuthClient;
    private JwtTokenProvider jwtTokenProvider;

    @Autowired
    private AuthService authService;

    @BeforeEach
    void setUp() {
        memberRepository = Mockito.mock(MemberRepository.class);
        oAuthClient = Mockito.mock(OAuthClient.class);
        jwtTokenProvider = Mockito.mock(JwtTokenProvider.class);
    }

    @DisplayName("Authorization code를 받아서 JWT를 발급한다.")
    @Test
    void getJWTToken() {
        Mockito.when(oAuthClient.getAccessToken(any())).thenReturn("access-Token");

        Mockito.when(oAuthClient.getProfile())
                .thenReturn(new Member(1L, 1L, "github-user", "https:/profile/image", "https:/profile"));

        Mockito.when(memberRepository.save(any()))
                .thenReturn(new Member(1L, "github-user", "https:/profile/image", "https:/profile"));

        Mockito.when(jwtTokenProvider.createToken(any())).thenReturn("Bearer jwt-token");

        assertThat(authService.createToken("authorization-code"))
                .usingRecursiveComparison()
                .isEqualTo(new TokenResponse("jwt-Token"));
    }
}

지금은 사라진 코드이지만, 로그인 서비스 테스트에 작성했던 코드입니다.
위 코드에서 확인하실 수 있듯이, Service는 프로덕션 객체를 사용하고 나머지는 Mock를 사용한 코드입니다.

추가적으로 상황을 덧 붙이지만 현재 서비스에서는

1. github client에게 ahtorization code를 받고, 이를 통해 access token을 요청한다.
2. access token을 통해 사용자 profile 정보를 받는다.
3. 받아 온 정보를 사용자 프로필 정보를 DB에 저장한다.
4. 사용자 정보를 사용하여 JWT를 발급한다.
   라는 과정이 한 flow로 진행되고 있습니다.

Mock 객체로 테스트를 작성하면서, 생각한 장점을 정리해 보았습니다.

1) 흐름도 역할을 한다.

위에서 작성한 테스트를 통해 로그인 기능의 flow를 한번에 확인할 수 있었는데요.
mock을 사용하니, 각 동작에서 필요한 요청과 응답을 정리하며 전체 flow를 정리할 수 있었습니다.
해당 테스트를 작성하고 개발을 진행하니 방향을 잃었을 때, 참고하기 매우 좋았습니다.

2) 현재의 추상적인 문제를 구체화될 때까지 미룰 수 있다.

원래 구현을 진행할 때 계획했던 방향은, Mock 객체로 테스트를 작성하여 개발을 진행하고,Service가 완성되면 프로덕션 객체로 바꾸자였습니다.
하지만 당시에 고려하지 못했던 점은, 해당 기능은 외부 API와 강하게 결합되어 있다는 것입니다.
따라서 저희가 제어할 수 없는 부분이 많았기 때문에, 애초에 프로덕션 객체로 테스트하는 것이 불가능했습니다. (jwt token이 어떤 것일지 알 수도 없고, github에서 어떤 값을 응답해줄지도 알 수 없습니다.)

Mock으로 테스트를 진행하니 해당 문제를 어느 정도 개발을 진행한 다음에야 직면할 수 있었는데요. 따라서 해당 기능이 필요한 시점에, 문제를 직면할 수 있었습니다.
만약 모킹을 사용하지 않았다면, 우선적으로 기능이 아닐 수 있음에도 불구하고, 구체화되지 않은 문제로 인해 개발이 딜레이 됐을 것이라 생각합니다.
따라서 모든 기능을 구현한 후에, 최대한 실제 동작과 가깝게 테스트하도록 MockMVC와 MocRestServiceServer를 사용해서 테스트하도록 바뀌었습니다.

3) 작은 단위에 집중할 수 있다. TDD를 더 잘할 수 있다.

mock 객체를 사용하니, 현재 해결해야 할 기능만 구현해 나갈 수 있었습니다.
저의 경험으로 미루어 볼 때, Top-Down 방식에서 mock을 사용하지 않으면, TDD를 잘 지키기 어려웠던 것 같습니다.

단점은 역시 실제 동작에서 잘 동작하지 않을 수 있다는 점인 것 같습니다.
Mocking을 많이 사용할 수록, 실제로 잘 동작할지 걱정되는 것은 어쩔 수 없네요.. 🥲
따라서 적절하게 사용하는 것이 매우 중요하다고 생각합니다.

혹시 Mock 객체 사용에 대한 생각이 있다면, 공유부탁드려요 ~ 🙌

글 전문

[verus-j]

일단 Mock으로 풀어가다가 Mock으로 사용하던 객체가 구현이 완료되면 바꾸는 방식이 좋아보입니다.
현재 Mock으로 해둔 부분들이 나중에는 테스트와 프로덕션 코드 간 결합도로 살짝 고치기 힘들더라구요...
그리고, 외부 요소(DB, Github OAuth 등)들 중 제어가 가능한 요소(DB)외에 제어가 불가능한 요소(Github OAuth)는 상황에 따라 목으로 대체해도 된다고 생각합니다. 물론, E2E 테스트 답게 전체의 과정을 볼 수 있으면 그게 베스트죠