테스트 코드 작성 시 유의할 점 (Mockito doNothing)

https://github.com/xpmxf4/HaeChuk-Gallery/blob/main/src/test/java/HailYoungHan/Board/controller/CommentControllerTest.java

CommentController 라는 Controller 중 하나

위는 다 작성된 테스트 코드입니다.

중간에 오늘의 주제가 있는 데 바로 doNothing입니다.

CommentService 의 addComment

해축갤 프로젝트에서 댓글 생성을 담당하는 Controller의 API 슬라이스 테스트 코드를 작성 중에 쓴 글입니다.

 

이 함수는 dto를 파라미터로 넘겨받아 Entity 객체로 전환 후,

이를 repository를 통해서 save 하는 함수입니다.

 

CommentService는 Mock 객체이기 때문에

사실할 이유가 없어도 무방하지만 그래도 하는 게 좋은 이유가 있습니다.

CommentService의 메서드는 언젠가 변경이 있을 수 있다.

 

CommentService 의 메서드는 언젠가 변경 가능하다

Mock 객체이기 때문에 side-effect 가 없다고 해도 무방하기에,

지금 상황에서는 doNothing 처리가 필요가 없긴 합니다.

 

"지금 상황에서는" 말이죠.

 

제 해축갤 프로젝트는 학습용 사이드 프로젝트이지만,

단순히 CRUD를 구현하고 끝날 프로젝트가 아니라 추후 이런저런 기술들을 갖다 붙일 키메라 프로젝트 이기도 합니다.

키메라 해축갤...?

모든 것들이 언젠가 변경이 일어날 수 있다는 거죠.

즉 addComment 도 언젠가 변경이 일어날 수 있고

언젠가는 예외를 던지는 함수로도 변경이 가능할 수도 있습니다.

 

제가 예전 글에서 이렇게 말한 바 있습니다.

'귀차니즘'이 많은 개발자냐고요?
네! 그거 잘못된 거 아니냐고요?
는 장난입니다만, 사실 진짜 알빠노이긴 합니다.

코래블러 ( ??? ~ )
[출처] : https://xpmxf4.tistory.com/68

 

전 필요하고 재밌는 일은 하겠지만 그 외에 불필요한, 의미 없는 노동은 할 생각이 없습니다.

진짜로,,,

즉, 최대한 컴포넌트 간의 변경에 대해서 서로가 영향을 최대한 안 받도록 코드를 짜는 것이

저의 희망사항을 지켜줄 수 있겠죠.

 

따라서 doNothing 은 먼 미래에 나를 위한 코드의 사용이다!

라고 말할 수 있겠습니다.

결론

슬라이스 테스트 시에는 최대한 결합도를 낮게 하자!!

그 방법 중 하나는 doNothing처럼 side-effect를 최대한 줄이자!