테스트 하기 좋은 코드, 좋은 테스트 코드

이 글을 쓰는 이유

좋은 테스트 코드, 테스트하기 좋은 코드에 대해서 고민하다가 든 생각을 공유해보고자 적습니다.

 

테스트 하기 좋은 코드

1. 블랙박스 테스트할때 비즈니스 로직의 결과를 단언할 수 있는 코드가 테스트 하기 편하다.

비즈니스로직과 persist 작업이 한번에 이뤄지고 "OK"나 Unit 과 같은 결과물만 내놓으면 stubbing으로 내용이 잘 돌아갔음을 증명해야하고, 이렇게 되면 레포지토리 레이어까지 내려가서 테스트해야한다. "버그 없음"은 테스트 코드를 통해서 증명할 수 있는게 없기 때문에, return을 받아서 결과를 볼 수 있도록 되어있는게 편한 것 같다. 파라미터로 넣은 객체를 확인하는 방법도 있지만, 객체는 Immutable하게 유지해주는 편이 좋기 때문에 비즈니스 로직은 묶어서 DTO를 반환하는 식으로 테스트할 수 있으면 편한 것 같다.

2. 설정해줘야하는 부분이 많은 빈을 주입받는 경우보다는 미리 다른 클래스로 한번 더 묶어서 미리 빈으로 만들어두는게 테스트하기 더 편하다.

이 예시를 적은 이유는 Webclient 때문인데, WebClient 목킹하려고 하면 벌써 피곤하다. Webclient를 주입받고 post하는데 필요한 데이터만 chaining 할 수 있도록 spec을 반환하는 메소드를 제공하는 클라이언트 클래스를 구현하면 나중에 테스트 작성하기 편한 것 같다.

양이 많아보이는 작업이 될 수 있지만, 단축키로 할 수 있는 일이 오토컴플리션을 반복하는 것보다는 더 빠르다고 느껴졌기 때문에, 그리고 이 spec을 모두 Mocking하는 것보다는 편한 일이기 때문에 이런 빈을 미리 등록해서 쓰는게 더 편하다고 느껴진다.

3. 많이 쪼개져서 부분부분 테스트할 수 있는 코드가 좋다

데이터레이어랑 코드를 섞어두지는 않았어도 한 메서드가 너무 길고(이미 여기에서부터 어렵긴한데) 테스트 케이스가 뎁스가 깊어지는 경우는 테스트하기 힘들다. 함수를 잘게 쪼개면 테스트를 작은 단위로 하고 이 작은 단위의 결과를 조합하는 결과의 테스트를 하려는 경우는 가장 작은 단위의 테스트 결과를 stubbing해서 테스트할 수 있기 때문에 테스트의 복잡성을 줄이고 프로그래머의 인지능력을 유지한 상태로 테스트할 수 있게 만들어준다.

 

좋은 테스트 코드

"필요한" 부분을 잘 증명한 테스트 코드

테스트 커버리지 100%, 찍으면 멋있겠지만 위에서 이야기했다시피 테스트코드 짜는 것도 피로가 쌓이는 작업이다. CRUD, 불필요한 stubbing과 mockking을 하고 그 라이브러리가 정상 동작함만을 알릴 뿐인 테스트 코드는 좀 지나치고, 비즈니스 로직을 잘 증명한 코드가 좋은 테스트코드 인 것 같다. 의도를 가지지 않은 사람은 아무 작업도 하지 않기 때문에, 코드가 짜여져 있는 경우 항상 의도가 있을 것이다라는 가정하게 보고자한다. 그런데, 이런 검증된 부분을 테스트하는 코드가 계속 발견된다면, 점차 혼동을 줄 수 있기 때문에 테스트 커버리지에 목메달리기보단 다음 사람이 와서 보더라도 이 코드는 꼭 파악해야해요 하는 부분들에 대해서 테스트가 짜여져있는게 좋은 것 같다.