구름 커밋 "프론트엔드 테스팅과 설계" 참여 후기

참여 계기

구름은 매달 다양한 주제로 '커밋'이라는 세미나를 진행하고 있습니다. 3월 주제는 '프론트엔드 테스팅과 설계'였는데, 마침 요즘 가장 고민하고 있는 주제라 꼭 듣고 싶었습니다.

5년 전부터 개발이 시작된 프로젝트를 담당하고 있다 보니 자연스럽게 리팩터링과 관련된 아티클에 눈길이 갑니다. 토스 기술 블로그에 있는 '달리는 기차의 바퀴 교체하기'를 인상 깊게 읽었는데, 이 글을 작성해 주신 분이 연사로 참여하신다니 기대가 되었습니다. 리팩터링 중인 프로젝트에 테스트 코드를 도입하는 데 도움이 될 것 같아 신청했습니다.

세미나 내용

유익했던 내용을 일부 정리했습니다.

테스트 대상

기능을 테스트해야 하며 구현이 테스트에 드러나면 안 된다.

Counter 컴포넌트 예시를 통해 이 문장의 의미를 이해할 수 있었습니다.

또 다른 예시는 renderHook입니다. Q&A 시간에 renderHook으로 커스텀 훅을 테스트하는 방식에 대한 질문이 있었습니다. 훅의 구현이 드러나는 renderHook 대신 컴포넌트를 하나 마운트하고 그 컴포넌트에서 훅을 사용하는 방법을 추천해 주셨습니다.

테스트 전략

테스트에 대한 오해 바로 잡기, 테스트가 어려운 이유 알아내기, 어려운 이유를 해결할 계획 세우기

한재엽님 블로그에서 자세한 내용을 확인할 수 있습니다.

• 테스트에 대한 오해와 사실
• 테스트가 어려운 이유

프론트엔드 애플리케이션은 어딘가(ex. 브라우저 환경, 서버와의 커뮤니케이션)에 의존하고 있다는 점 때문에 테스트를 어렵게 만듭니다. 의존성을 관리하기 위해서는 외부 의존성인지 인프라인지 식별하고 적절한 관리 방법을 선택해야 합니다.

의존성을 주입하게 되면 구현이 드러나지 않고, 변경에 내성이 강해지며, pure javascript object로 표현이 가능하다는 장점이 있습니다. 하지만 제품 설계의 변경이 필요하다는 단점도 존재합니다.
반면 mocking은 구현이 들어가서 테스트가 깨지기 쉬워집니다. React를 Vue로 바꾼다면 모든 테스트가 깨지겠죠?

테스트 전술

테스트 코드를 작성하는 비용과 테스트 코드로부터 오는 효용을 잘 비교해야 합니다. 토스페이먼츠는 제품이 나가면 가맹점에서 빼주지 않는 이상 영원한 제품이 되기 때문에 테스트 코드를 많이 작성하는 편이라고 합니다. 또한 결제라는 도메인은 장애가 발생하면 리스크가 크기 때문에 장애 비율을 낮추고자 하는 공감대가 있었고, 이로 인해 비교적 수월하게 테스트 코드를 도입했다고 합니다. 제품 레벨에는 유닛 테스트만 존재하고, E2E 테스트는 오토메이션 팀에서 담당한다는 점도 흥미로웠습니다. 결제 시스템을 테스트하려면 실제로 천 원 결제를 일으켜야 하기 때문에 개발자 혼자 E2E 테스트하기 어려운 시스템이라고 합니다. 이처럼 개발자 관점에서 E2E 테스트가 비용 대비 실익이 크지 않다고 판단될 때, 테스트 담당을 분리하는 것도 현명한 선택이라고 생각합니다.

SDLC에서 우측으로 갈수록 오류가 검출되는 타이밍이 늦어집니다. shift left는 5단계인 테스팅을 4단계인 소프트웨어 개발과 함께 진행해 오류를 조기에 발견하는 방식입니다. shift left보다 더 앞 단계에서부터 테스트를 고려하자는 의미로 shift front라는 단어를 사용하셨습니다. 결국 테스트에 용이한 설계가 중요하다고 생각합니다.

마무리

새로운 기능 구현이 우선시되던 과거 업무 경험과 달리, 이제는 제품 리팩터링과 고도화에 대부분의 시간을 투자하고 있습니다. 소프트웨어는 변경이 기본임을 인지하는 순간 테스트는 같이 따라가야 한다는 말을 실감하는 중입니다. 코드 측면으로는 회사 프로젝트에 vitest를 도입하고, 설계 측면으로는 세미나에서 추천받은 책을 읽으면서 무게 중심을 점차 테스트로 옮겨가고자 합니다.