개발자
안녕하세요. 2년차 프론트엔드로 일하고 있는 주니어입니다. 사내에 테스트코드 도입 전 혼자 해보고있는데요, tdd를 하고 계시는 다른 현직자 분들에게 궁금한점이 있습니다. 유닛 테스트 : jest, vitest E2E 테스트: cypress, playwright 위의 도구로 이것저것 해보고있는데 하면서 까다로운 점이 있습니다. 일반 유틸 함수 같은 것은 유닛테스트가 비교적 간단하지만 프론트 엔드이다 보니 컴포넌트 테스트를 하려면 무조건 DOM 으로 불러와야하고, 사이즈가 큰 컴포넌트는 뭔가 잘 되지도 않고, 이럴거면 그냥 E2E만으로 하면 되지 않나 라는 생각도 들고... 실제로는 unit 테스트 도구로 컴포넌트 dom으로 불러와서하고 e2e도 따로 하시나요? 아니면 e2e로만, unit으로만 이렇게 한가지로만 하시나요??
답변 2
jest 언급하신 것을 보니 react 기반인 것 같아 그렇게 가정하고 또 유닛테스트에 경험이 거의 없는 입문자라고 가정하고 답변드리겠습니다. 일단 리액트는 "상태변경 -> ui 갱신" 이게 핵심인 만큼 상태변경이 제대로 되는지를 잘 테스트하는게 가장 중요합니다. 예를 들어 "내가 ~~~한 행동을 하면 zustand에 들어있는 a라는 값이 3 증가해야해" 이런거가 의도대로 작동되는지를 확인하는거죠. 그리고 저런게 잘 작동된다면 저런 상태 변경에 따라서 컴포넌트가 잘 렌더되는지를 확인하는겁니다. 그리고 이걸 dom을 죄다 render해서 다 확인하려고 하면 한도 끝도 없기 때문에 제가 추천드리는 것은 대상이 되는 컴포넌트를 shallow render 한 다음, 해당 컴포넌트의 자식들의 구성이나 갯수 정도만 확인하는 겁니다. 예를 들어 다음과 같은 구성의 컴포넌트가 있다면 <부모> <버튼 완료> <버튼 진행중> <버튼 전부> <자식>1</자식> <자식>2</자식> <자식>3</자식> ... <자식>9</자식> <자식>10</자식> </부모> "<버튼 완료>를 누르면 자식이 3개만 렌더 되야 함" "<버튼 진행중>을 누르면 자식이 7개만 렌더 되야 함" "<버튼 전부>를 누르면 10개 전부 렌더 되야 함" 이렇게 간단한 시나리오를 구상해놓고 자식 1~10을 렌더하기 위한 더미 데이터도 시나리오에 맞게 잘 준비해 놓은 다음, 시나리오 별로 <부모>를 렌더했을 때 <자식>의 갯수가 맞는지 확인하는 tc들을 작성하는겁니다. 물론 실무에서는 시나리오들이 이 것보다는 복잡할텐데, 그건 저런 간단한 내용들부터 먼저 해보고 차근차근 익숙해진 다음에 고민하면 되는 문제이고, 그게 아니면 저런 간단한 시나리오로 테스트할 수 있는 단계까지 컴포넌트들을 더 작게 쪼개는 방법도 있습니다. 참고로 컴포넌트가 기능이 너무 많고 구조가 복잡한 경우 tc 작성을 많이 해본 숙련된 개발자도 만들기 아주 짜증나고 답 안나오는건 똑같습니다. 저 같은 경우 실제 테스팅에 적합한 형태로 리펙토링을 하는 과정에서 구조가 개선되는 경우를 많이 경험했습니다. 그리고 끝으로 e2e와 유닛테스트는 그냥 별개로 생각하셔야 합니다. 저 같은 경우 둘다 하는 경우도 있었고 유닛테스트만 하는 경우도 있었고 그랬습니다. e2e만 하는 경우는 저는 경험해보지 못했네요. (e2e만 하는게 안좋다거나 이상하는 뜻은 절대 아닙니다!) e2e 테스트는 브라우저에서 작동 되므로 "스크롤을 ***까지 이동한 다음 1초 지났을 때 xxx 레이어가 생성됐는지 확인"과 같은 유닛테스트로는 절대 할 수 없는 영역까지 테스트할 수 있는 장점이 있습니다만, "코어 의존성의 버전을 올렸더니 빌드 에러는 없는데 ** 버튼 눌렀을 때 exception 나오네?" 이런걸 캐치하는데에는 유닛테스트가 훨씬 가볍고 좋습니다. 물론 익셉션 발생 했는지 여부 같은건 e2e 테스트 도구에서도 다 확인이 가능하긴 합니다만 저런걸 확인하는 용도로는 상대적으로 무겁고 불편합니다. 때문에 여력이 되신다면 둘 다 하시는걸 추천하고 싶은데... 이게 쉽지가 않긴 하죠. ㅋ
지금 가입하면 모든 질문의 답변을 볼 수 있어요!
현직자들의 명쾌한 답변을 얻을 수 있어요.
이미 회원이신가요?
지금 가입하면 모든 질문의 답변을 볼 수 있어요!