오늘은 뭔가 한 것은 많은데, 쓸 내용은 생각보다 없는 것 같다?
어떤 것이 E2E 테스트?
E2E 테스트에 대해 고민을 하던 중 리더님이 이런 이야기를 해주셨다.
나는 DB를 메모리에 띄워서 조금 더 빠르게 돌리는 것을 고민할 때
프로덕션과 유사하게 테스트를 하기 위해서 E2E를 돌리는 것인데
메모리에 돌리면 환경이 조금 달라지기 때문에 E2E의 목적과 다를 수도 있다는 이야기를 해주셨다.
다른 분의 의견이 더 궁금해져서 뒤를 지나가시던 CTO님을 붙잡아가지고 여러가지 이야기를 들을 수 있었는데
E2E 테스트를 할 때, 메모리에 올리려고 하는 것은 한번 돌릴 때 느리기 때문에 올려보려고 한다.
내가 생각하던 것과 같은 이야기를 해주셨고 유닛테스트가 불필요한 것 같아서 E2E를 짯다고 이야기를 했더니
- 유닛테스트가 정말 불필요한 것이 맞는지
- 혹은 잘못 생각하고 있는게 아닌지
에 대해서도 고민을 해보는게 좋을 것이라고 조언을 해주셨다.
그러면서 리더님과 CTO님 두분 다 테스트라는 영역이 정말 거대한 산처럼 수많은 정보가 있기에
이것만을 하는 파트도 있다고 하셔서 여기도 다양한 지식이 있다는 것을 조금 맛 본 느낌이랄까.
추후에는 E2E가 순차적으로 켜지는게 아니라, 인스턴스를 한번에 다 켜서 돌리는 것을 연구해보라고 하시던데
이게...돼....? 로컬에서 돌릴꺼니 어떻게든 될 것 같기도 해서 좀 찾아봐야 할 것 같다.
오래된 코드를 분리해보자!
레거시 코드 분리 작업을 진행했다.
기존의 거대한 모듈을 잘게 쪼개고
TypeORM 버전업을 할 때 조금 더 쉽게 변경 작업을 할 수 있도록 데이터 레이어 분리 작업을 하고
오래된 코드라서 아쉬웠던 검증단과 속도 부분에 힘을 줄 수 있도록 크게 개선을 진행했다.
RESTful 하지 못했던 API에 대해서도 Path라던가 Method를 재정립해서
확실히 폴더구조가 깔끔해지고, 모듈간의 의존성에 대해서도 많은 분리가 이뤄졌다.
또한 에러가 발생했을 때 에러로그만으로는 추적하는 것이 아쉬운 부분이 많았는데
이러한 부분에서도 조금 더 명확하게 추적을 할 수 있도록 에러에 대한 명시도 자세하게 작성을 했다.
마지막으로는 기존의 유닛테스트에 대해서 조금 더 세밀하게 테스트를 하고자 E2E 테스트를 추가했는데
아마 여러가지 시나리오를 더 추가해봐야 할 것 같다...?
요즘 일이 쥰나게 많다
백엔드 개발자 뽑아주세요 프론트말고....
