회고
QueryDSL
QueryDSL을 사용하는 것은 약 5년만인 것 같은데, 기억이 많이 나지는 않지만 전과 달라진 점이 많아 익숙하지 않았다. 그래서 이해하는데 시간이 생각보다 더 걸렸다.
테스트 환경
알림 서비스가 참 체계적으로 추상적으로 잘 구분되어있지만 프로세스가 복잡하다. CRUD가 아니라 딥한 비즈니스 로직이라서 그럴 수도 있지만, 테스트를 할때 많이 체감이 되는 것 같다.
- 카프카로 팀원의 메시지를 수신.
- 다른 서비스에 접근해 데이터를 조합.
- 템플릿 구조에 바인딩 후 슬랙 전송.
- 히스토리에 저장
테스트 데이터
어제는 더미 데이터를 로직 곳곳에 셋팅을 하면서 진행했다. 그런데 브랜치를 이동하면서 테스트 관련 로직이 유실되어 난감했다.
이런 방식의 테스트가 반복되어 진행할 것 같아, 테스트 환경(더미 데이터, 환경 설정 매핑, 테스트용 API)을 구축하려고 했다.
진행하다 느낀 것이 생각보다 오래 걸릴 것 같았고 효용성이 부족해보였다. 그리고 운영 서버에 포함되면 안되는 기능이기도 해서 관리를 신경써야하는 것도 문제였다. 그래서 DB에 수작업으로 데이터 구조를 작성해서 직접 로우를 넣었다. 그 과정에서 실제 프로세스 사이사이에서 변환을 거친 형태의 데이터가 되어야했다. 리터럴 문자나 통신을 거치는 과정에서 데이터가 변경되는 부분이 있어 시간이 더 소요됐다.
테스트 코드 필요성
지금과 같은 실제 API를 통한 테스트를 하기 위해서 테스트 환경을 갖추는게 낭비되는것 같아 아깝다는 생각이 들었다. 만약 테스트 코드를 잘 다룰 수 있었다면 지금 같은 상황에서도 쉽게 확인하고 넘어갈 수 있을지 궁금해졌다. 지금 생각으로는 외부 API와 타 서비스 통신이 많기 때문에 어쩔 수 없는 것 같기도 하다.