최근 (아직도) 구직중에 많은 면접관님들과 프론트엔드 테스트에 관한 이야기를 했습니다. 많은 회사에서 우대사항으로 프론트엔드 테스트 경험을 기재하시고, 면접에서도 프론트엔드 테스트에 대한 갈증을 보이고 계십니다.
하지만 테스트를 잘 활용하는 곳은 손에 꼽을 정도로 적고, 그중에서도 TDD에 대해서는 실제 현업에서 적용하기엔 무리가 있다는 반응이 거의 대부분이였습니다. 프론트엔드에서 TDD가 어려운 것은 다음과 같은 이유가 있습니다.
프론트엔드에서 테스트가 어려운 이유
- 테스트 자체가 어려운 환경이 많다.
- 테스트 코드를 작성하는 시간까지 개발 과정에 포함되므로 오래 걸리고, 테스트 코드를 유지보수해야 한다.
- 서버 api 목킹, 라우팅 등의 테스트 세팅이 어렵다.
- 이벤트 페이지와 같이 생명주기가 짧은 코드의 경우 테스트 활용성이 낮다.
- 어떤것을 테스트 해야하는지, 적절한 테스트 범위를 설정하는게 어렵다.
TDD를 갈망하면서도 현업 프로젝트에 적용할 수 없는 가장 큰 이유는, 우리는 돈을 받고 일하고, 시간이 부족하고, 우리의 시간은 회사의 돈이기 때문입니다. 제대로 하지 못하면 시간만 축내는 테스트를 회사 차원에서 이해해줄리가 없습니다.
방안
앞서 말한 단점에 대응하기 위해 다음과 같은 방안이 있습니다.
-
단순 이벤트 페이지와 같이 생명주기가 짧아 재활용이 어렵고, 로직이 간단하여 테스트 코드가 필요하지 않는 경우 테스트 하지 않는다.
=> 면접 중 한 CTO님께 들은 얘기로 토스에서 이렇게 진행한다고 합니다. 모든 코드가 테스트할 필요가 있을까에 대해 고려해 볼 필요가 있습니다. -
사용하는 테스트 도구에 대한 숙련도를 높인다.
=> MSW등을 통한 백엔드 api 목킹, 라우팅 및 브라우저 api 목킹 등 어려운 테스트 케이스에 대한 경험이 쌓이면 앞선 단점을 대체로 개선할 수 있습니다. -
(중요!!!) 좋은 테스트 코드를 작성한다.
=> 코드가 그러하듯 테스트 코드에도 좋고 나쁨이 있고 품질이 있습니다. 테스트 또한 유지보수가 필요한 코드임으로, 좋은 코드를 작성하는 규칙들과 같이 좋은 테스트 코드를 작성하는 여러 규칙과 방법론들이 있습니다. 테스트에 관한 책들이 많이 있으니 별도 학습을 통해 테스트 방법론을 익히는 것이 중요합니다.
TDD의 장점 (일부)
-
요구 사항에 대한 정확한 구현 및 확인이 용이하다.
=> 코드 작성에 앞서 테스트 코드를 작성하기 때문에 요구사항을 충족하는 코드를 정확히 작성할 수 있습니다. -
모든 상황과 화면을 구현하지 않고도 확인이 가능하다.
=> 일일히 화면을 클릭해가며 구현사항을 반복하는 대신, 테스트 코드 환경에서 환경을 조작하면서 확인할 수 있습니다. 로직 확인을 위해 같은 화면을 수동으로 확인하는 과정을 최소화하여 생각보다 많은 시간 세이브가 가능합니다. -
(중요) 변경 사항이 생겼을 때 다른 부분이 영향을 받지 않았는 지 즉시 확인할 수 있다.
=> 현업에서 테스트를 도입할 가장 큰 명분이자 장점이라고 할 수 있습니다. 개발 기간 산정할 때에 향후 코드 변경 대처 및 디버깅 시간까지 포함한다면, 테스트 코드 없이 개발하는게 무조건 빠르다고 단언할 수 없을 것입니다.
이 외에도 다른 장점들, 그리고 모든 것을 테스트할 수 없다는 한계점 또한 있으나 본 글에서는 생략하도록 하겠습니다.
필자 사례 (feat.과제)
최근 진행한 프론트엔드 채용 과제를 TDD 싸이클로 개발하기로 했습니다.
((구현전이므로 실패하는) 테스트작성 -> 코드구현 -> 테스트 성공)
테스트에 대한 관심과 차별점을 보여드리고 싶은 의지가 있었고, 기간이 충분하여 TDD 싸이클로 개발을 하기에 충분한 기간이 있는 과제였기 때문입니다.
과제 수행 프로세스
-
프로젝트 세팅 및 테스트 환경 세팅
(Vite, React, Typescript, Vitest, React-testing-library, MSW, Cypress (추후 추가)) -
요구사항 분석을 바탕으로 페이지 파일 생성, 페이지 단위 테스트 파일 생성
-
테스트 파일에 요구사항 기재 및 분석하여 테스트 코드 작성.
=> 테스트 코드 변경을 최소화 하기 위해 요구사항 기반하여 UI 테스트 코드 작성. -
구현 시 테스트를 백그라운드에서 실행시키며 코드 작성
=> 작성한 코드의 유효성을 UI 조작 없이 즉시 확인할 수 있음 -
테스트 성공
=> 야호 -
코드 수정 시 테스트 코드 전체 실행하여, 사이드 이펙트 및 테스트 코드 수정 필요 여부 확인
-
Cypress를 통해 RTL로 확인하기 어려운 유저 시나리오 테스트
느낀점
오랫 동안 공부하며 시행착오를 겪었던 프론트엔드에서의 TDD와 테스트에 대해 감을 잡은 느낌을 받았습니다. 책을 통해 공부했던 장점들을 체감할 수 있었던, 왜 테스트에 대한 책까지 써가며 테스트를 전파하려는지 공감할 수 있었던 경험이였습니다.
코드 작성 중
코드를 작성해나가며 매번 UI로 확인하는 대신, 코드를 통해 즉시 확인 가능했기 때문에 불필요하고 반복적인 확인 과정을 줄일 수 있었습니다. 탄탄한 코드를 써내려가면서도 TDD의 가장 큰 단점인 시간 소모의 단점이 다소 해결되는 부분이라고 볼 수 있겠습니다.
아직 UI로 직접 확인하기 전이지만, 테스트한 상황 내에서는 내 코드가 잘 동작하리라는 것을 알고 있다는 느낌이 매우 좋았습니다.
완성 후 (수정 중)
추가 구현하고 싶은 부분, 리팩토링을 할 때에 가장 큰 도움이 됐습니다. 현업에서 코드를 수정할 때 가장 두려운 부분이 바로 사이드 이펙트인 것을 고려하면, TDD와 테스트가 왜 개발자들의 로망인지 알 수 있습니다. 테스트 코드가 없어서 배포 전 일일히 확인하고, 배포후에도 직접 확인하고, 실시간 데이터를 모니터링하면서 문제가 없길 바라는 일을 줄일 수 있을테니깐요.
