팀프로젝트 도중 Mock과 관련해서 궁금한 점

저도 완전히 동일한 생각을 했었습니다. 여전히 많이 공감하구요. 하지만 실제로 프로젝트가 복잡해지고, 마이크로서비스화 되고, 개발/스테이지/리얼 등 페이즈가 분화되면 실제 액터들을 테스트에 참여시키기 불가능한 상황이 많습니다. 예를 들어 db 의존성을 Mocking하지 않는다면, 페이즈별 db를 따로 운용해야될 수도 있겠죠. 그리고 테스트 사이즈가 커져서 병렬로 테스트를 돌리고자 한다면, 실제 db의 상태가 추가되어 stateful 해지기 때문에 멱등성 보장이 안되어 병렬 테스트가 불가능 할 수도 있습니다. 마이크로서비스화 되어, 내가 구현한 서비스의 단위테스트가 다른 서비스의 장애(특히 dev 환경이면 안정성이 떨어지니까요)에 의해 실패할 수도 있죠. 처음부터 타 서비스 장애를 상정한 테스크 케이스가 아니라면, 성공을 보장해야 되는 테스트가 실패하면 안되겠지요? 이런 상황들을 생각해보면 Mocking이 의미가 없는거 아닌가요? 라는 질문에 쉽사리 네, 의미없죠 라고 하기 어렵습니다. 그리고 같은 논점에 대해서 토론했던 동료 중에 한 분은, Mocking을 잘못하면 예측에 실패해서 테스트는 다 통과했지만 오류가 발생할 수 있는 것 맞다. 근데 이건 개발자의 예측 실력이 부족했던 건 아닐까? 라고 반문했었던 적이 있습니다. 참… 실력으로 퉁치는 것만큼 비겁한 논거도 없는 듯 합니다만… 또 틀린 말는 아니기도 합니다. 왜냐면 원래 테스트 케이스는 모두 예측이죠. Mocking을 쓰지 않더라도, 잘 설계된 테스트가 없다면 테스트를 모두 통과해도 운영상 오류가 발생하는 것은 매한가지입니다. 테스트를 잘 만드는 것과 마찬가지로, Mocking을 잘 만드는 것도 실력이 아닐까 생각해볼만 하죠. 결론을 내보자면, 복잡하지 않은 시스템이라면 Mocking을 하지 않는편이 더 나을 수 있다고 생각합니다. 이러나 저러나 실제 객체로 테스트 해보는 것만큼 정확할 순 없겠죠. 하지만 위에서 설명드렸듯이, 이미 복잡하거나 복잡해질 시스템일 수 있다면, Mocking을 잘하는 법을 연습해 보는 것도 좋을 듯 합니다.