[삽질로그] 트러블 슈팅 시간 단축하기

 작년 12월 6일 글또 백엔드 반상회에서 영인님이 발표하신 내용 중 '삽질로그'를 개발 과정에 적용해봤다.

개발을 하다가 트러블 슈팅 시간이 너무 오래걸려서 1월 23일에 갑자기 삽질로그 이야기가 떠올랐는데, 써보니 확실히 트러블슈팅 시간이 단축됐다.

 

 무엇을 모르는지 나의 언어로 정의해보지 않았던 것이 가장 큰 문제였다. 그냥 에러메세지 보고 '아 이게 뭐야..' 하면서 굉장히 수동적이고 기계적으로 chatGPT에게 질문했다. 몇 번 티키타카 해도 문제가 해결될 기미가 안 보이면 속이 답답해지고 아무것도 모르겠는 상태에 빠진다. 그러면 멘탈에 아주 좋지 않고 문제 회피성 도파민 샤워를 위해 유튜브를 몇 시간 보고 나서야 정신을 부여잡을 수 있었다. 그러다 보면 또 자괴감에 빠지고 악순환의 연속이었다.  

 

삽질로그 작성 전 개발 일상: 불-편

형식은 영인님의 삽질로그와 동일하게 썼고, 내가 쓴 삽질로그 일부를 가져와봤다.

나는 확실히 노트에 손으로 적을 때 잘 와닿고 정리도 잘 되는 것 같다.

 

 

# 문제1

 : ScheduleServiceTest 중 UserService를 의존하는 ScheduleService 로직을 테스트할 때 자꾸만 유저를 찾을 수 없다는 에러가 뜸

# 원인 파악

 : UserService를 모킹하지 않았다.

# 해결의 실마리

 : 유저를 찾을 수 없다는 에러가 왜 발생했을까 생각해보다가 ScheduleService가 UserSesrvice를 의존하는데 해당 테스트 클래스에서 UserService를 주입받지도, 모킹하지도 않는다는 것을 알아차렸다. 

# 삽질한 이유

 : UserRepository에 유저를 저장했기 때문에 UserService가 FakeRepo를 조회해서 유저를 반환해줄 줄 알았다.

# 삽질에 쓴 시간

 : 2일

# 액션 아이템

 : 내가 쓴 코드 찬찬히 다시 들여다보고 에러가 발생한 지점의 논리적인 인과관계를 손으로 써보기

 

# 문제2

 : 또 또 의존성 주입! PollScheduler는 Clock을 주입받아서 현재 시간을 제어할 수 있는데, 운영코드에서 @Bean으로 등록한 Clock과 테스트코드에서 @Bean으로 등록한 Clock이 충돌함

# 원인 파악

 1) 운영코드 ClockConfig에서 @Bean 위에 @Primary를 붙이고 테스트코드 TestClockConfig에서 @TestConfiguration을 클래스 위에 붙여서 어플리케이션 실행 시에는 ClockConfig가, 테스트 실행 시에는 TestClockConfig가 주입되는 것을 의도했는데 도대체 뭐가 문제지?

 2) 테스트 코드에서 테스트 클래스 위에 @Import(TestClockConfig::class)도 붙였다고.. 

 3) ClockConfig와 TestClockConfig의 메소드명이 동일했기 때문에 충돌이 발생함

 4) @Primary는 테스트 쪽에 붙여야 테스트 실행 시 우선 적용되어 @Primary도 TestClockConfig의 @Bean 위로 옮김

# 해결의 실마리

 : 에러로그를 보다가 'A bean with that name has already been defined in class path resource [com/example/antserver/testconfig/TestClockConfig.class]'를 발견함

# 삽질한 이유

 : Config에서 정의한 메소드가 @Bean의 이름이 된다는 것과 @Primary를 테스트 쪽에 붙여야 테스트 실행 시 우선 적용된다는 사실을 모름

# 삽질에 쓴 시간

 : 2시간!!

# 액션 아이템

 : 에러 로그의 Description과 Action을 꼭 확인하기

 

삽질로그 작성 후 개발 일상: 편-안

몇 번 쓰다보니 n일에서 2시간으로 트러블 슈팅 시간이 줄었다. 역시 뭐든지 메타인지가 중요하다.. 앞으로 항상 삽질로그를 작성해야겠다! 개발 생산성에 아주 좋은 것 같다.