들어가며
CLA 팀에 합류한 후, 가장 먼저 도입하고 싶었던 부분 중 하나가 테스트 코드였습니다. 코드를 파악하는 과정에서 잘못된 부분을 수정하기 위해 PR을 생성했지만, 내가 수정한 코드가 다른 부분에 영향을 미치거나 예상치 못한 이슈를 발생시키지 않을까 불안했습니다.
때문에 코드를 수정하거나 리팩토링할 때 보다 안전하게 작업할 수 있도록, E2E 테스트 환경을 구축하고 테스트 코드를 작성했습니다.
총 121개의 E2E 테스트 코드를 작성하였습니다.
Test DB 구성
테스트 진행 시 사용하는 DB를 어떻게 할지에 대해 두 가지 방안을 고려했습니다:
-
Test DB 구축
-
Docker를 통해 Test DB 띄우기
개인적으로는 2번 방법을 선호하지만, 현재 팀 상황에서는 1번 방법이 더 적합하다고 판단했습니다.
이유는 코드에서 TypeORM decorator를 통해 정의한 테이블과 실제 prod, dev 환경에서 구성된 테이블 정의가 다른 부분이 있기 때문입니다.
Docker로 Test DB를 띄운 뒤,
TypeORM sync를 사용해 DB를 구축할 경우,
실제 DB와 다른 환경에서 테스트가 이루어져 테스트 신뢰성이 낮아질 수 있습니다.
따라서 dev 환경과 동일한 test DB를 구축한 후, 해당 test DB를 통해 테스트를 진행하도록 테스트 환경을 구축하였습니다.
Circular Dependency 이슈
문제점
createTestingModule을 사용해 Nest 애플리케이션을 빌드할 때, import하는 모듈에 circular dependency가 존재하면 빌드가 되지 않는 이슈가 존재하였습니다.
해결 방안
circular dependency가 발생하지 않도록 common module을 만들어 해결하였습니다.
예를 들어,기존 A Module과 B Module 간의 circular dependency를 해결하기 위해 ABCommon Module을 만들어서 문제를 해결했습니다.
NestJS로 개발 시, 개발자는 코드 작성 시, 순환 참조가 발생하지 않도록 주의해야 합니다!
테스트 코드 도입 이후 GitHub 워크플로우 변경 사항
- 개발자 작업
- Develop 브랜치 최신화
- 기능 구현을 위한 Feature 브랜치 생성
- 기능 구현 완료 후, Develop 브랜치로 병합을 위한 PR 생성 및 코드 리뷰
- 이 단계에서, Test CI가 통과해야만 병합할 수 있는 규칙 적용 - Dev 브랜치 병합
- Main 브랜치 병합 시, PR 생성
- 이 단계에서도, Test CI가 통과해야만 병합할 수 있는 규칙 적용 - Main 브랜치 병합
- 추가 사항: 배포 스크립트에서 테스트가 통과되어야 배포될 수 있도록 수정
E2E 테스트 코드 및 워크플로우 변경으로 얻을 수 있는 이점
-
E2E 테스트 코드 도입으로 인해, 코드 수정이나 리팩토링 시 보다 안전한 환경에서 작업할 수 있게 되었습니다.
-
CI가 통과하지 못한 경우, slack을 통해 알림을 가도록 설정하여 버그를 조기에 발견하고 수정함으로써 시스템의 안정성을 높일 수 있도록 하였습니다.
-
배포 스크립트가 테스트를 통과해야만 배포가 가능하도록 설정하여, 배포 전 안전장치를 확보하였습니다.
E2E 테스트 코드 및 워크플로우 변경으로 팀의 개발 생산성을 높였고 안정적인 제품 개발을 위한 기본적인 토대를 마련하였습니다.
