2021-05-29(Sat)

Facts (사실, 객관)

코드숨 4주차 과제의 요구사항인 테스트 커버리지 100%를 달성시켰다.

mockito의 활용에 대해서 고민했다. 이 과정에서 Mockito, 이대로 괜찮은가? 글을 읽고, 참고자료로 나와있는 우아한 테크코스 리뷰1, 우아한 테크코스 리뷰2, Mockito Test Framework 알아보기를 확인했다.

친구 결혼식장 가는 길에 '오브젝트' 책을 읽었다.

Feelings (느낌, 주관)

테스트 커버리지 100%를 달성시켰다. ProductService를 뜯어고치지 못 했기 때문에 아직 반쪽자리라고 할 수 있다. 흠 mock 객체에 메소드를 mocking하지 않았는데도 작동하는 메서드의 비밀을 풀기 위해 mockito를 탐구해보았지만, 원인은 mockito가 아니라 나에게 있었다. 테스트를 편하게 하기 위해 작성한 유틸 메서드에서 mock 객체가 아니라 진짜 객체를 생성해버린 것이다. 먼저 내 코드를 살폈어야 했는데 애꿎은 mockito를 의심했던 나를 반성해본다.

mockito를 조사하는 과정에서 자바블 블로그를 알게 되었는데, 유용한 글들이 많다. 이 글 저 글 읽다보니 시간이 훅 가버렸다!

Mockito, 이대로 괜찮은가? 글에 참고자료로 링크된 우아한 테크코스 리뷰가 상당히 고퀄리티이다. 특히 mockito를 쓰면서 느껴지던 위화감을 꼬집어주는 우아한 테크코스 리뷰2는 도움 되었다. 나도 누군가한테 이렇게 도움을 줄 수 있는 개발자가 되고 싶다. 로컬 저장소를 셋업해서 테스트 환경을 구축하는 것도 다음에 시도해봐야지!

스프링캠프 2019 - 무엇을 테스트할 것인가? 어떻게 테스트할 것인가?(권용근)는 내일 시간 나는대로 확인해봐야겠다.

Findings (배운 점)

mockito 사용의 기준

답은 없다지만, 하단은 설득력있는 kingbbode 님의 기준.

1. 제어할 수 없는 영역에서 사용한다.

2. 로컬 구성이 가능한 저장소는 사용하지 않는다.

3. 레이어링의 경계에서 사용한다.

특히 2번에 대해서는 장단에 따라 선택이 필요할 것 같다.

Mock 을 사용한 테스트

• 장점

  • 테스트가 빠르다

• 단점

  • 구현을 알게 되어 어플리케이션 코드 변경에 자유로울 수 없다.

  • 실제 DB를 통해 발생하는 문제를 캐치할 수 없다.

저장소를 사용한 테스트

• 장점

  • 실제 DB를 통해 발생하는 문제를 캐치할 수 있다.

• 단점

  • 저장소 설계를 알게 되므로 데이터베이스 설계 변경에 자유로울 수 없다.

  • Mock을 사용한 테스트에 비해 테스트가 느리다.

한편 나는 Mock 처리를 할 때 인터페이스에서 어떤 메서드를 사용할지 아는 테스트를 만들고 있다. 때문에 구현이 변경되면 테스트도 변경해야하는 사태가 발생한다. 비슷한 상황에 놓인 코드에 대한 우테코 리뷰어님의 코멘트는 아래와 같다.

Mock 처리를 한다면 하위 인터페이스를 완전히 구현하는 테스트더블 생성이 필요합니다. 그래야만 하위 레이어의 구현에 상관없이 유연한 테스트가 가능해집니다.

Affimation (자기 선언)

나는 문제를 확인할 때 침착하게 확률이 큰 것부터 체크하는 개발자다.

나는 지식을 열린 마음으로 받아들이고 역량으로 만드는 개발자다.