TN;DR:
서론 | 이론 정의
나는 테스트 코드를 짜본 적이 없다. 테스트 코드의 필요성은 알고 있었지만 (개발 과정에서 간과하는 실수가 많은 나는 늘 테스트가 부족하다) 회사에서는 권장하지 않았고 사용하는 사람도 없었기 때문이다. 그래서 이러한 과제를 받았을 때 이론부터 감을 잡아야 했다.
멘토님이 설명해 주신 다섯 가지의 테스트 객체(Dummy, Stub, Spy, Mock, Fake)는 나에게 너무 추상적이었다. 다 비슷비슷하게 보였다. 실제 사용해야 할 때 가장 적당한 것을 선택하기 힘들어 보였다. 그래서 일단 이들을 검색해서 닥치는 대로 예시를 읽었다. 아래는 내가 이해한 테스트 객체이다.
Dummy는 가장 정적인 객체로 보았다. 빈 껍데기만 필요할 때 사용하기 좋은 것 같았다.
Fake는 그보다는 조금 더 구체적 객체로 보았다. 하드코딩된 데이터베이스 객체와 비슷해 보였다. "완전히 독립적인"
Stub은 Dummy의 동작형으로 설명되던데, 하드코딩된 껍데기로 보였다. 의도한 결과만을 위한 껍데기다.
Spy는 호출된 횟수가 필요할 때 적합하다고 들었는데, 약간 이력을 확인하는 데에 특화된 객체 같다. Mokito의 verify와 같다고 한다. "일부만 조작"이라는 설명이 인상적이었다.
Mock은 가장 정교하고 자주 쓰이는 것 같았다. Mokito도 Mock의 일종이라고 한다. 가장 복잡하기 때문에 심플해야 하는 테스트 코드에서 에너지가 필요 이상으로 쓰일 수 있다는 그런 느낌이었다.
멘토님이 상태검증과 행위검증의 개념에 대해서도 설명해 주셨는데, 검색을 통해 리마인드하며 구체화할 수 있었다.
상태 검증은 인풋과 아웃풋을 바라본다. 블랙박스 테스트와 유사해 보였다. Stub이 주로 사용된다고 한다.
행위 검증은 디버깅처럼 라인마다 pass/fail을 확인하는 것 같았다. Mock이 주로 사용된다고 한다.
그리고... 다양한 글을 읽고 다시 멘토님의 정의를 보니 정말 간결하고 핵심만을 설명하는 문장들이었다. 이론이 쏙쏙 정리되었다.
E2E 테스트. 테스트코드가 컨트롤러도 아닌데 어떻게 호출하고 응답을 받는지 궁금했는데, mockMvc의 perform()을 사용하면 되었다.