프론트엔드 테스트코드 어떻게 하세요?

cypress를 쓰시면 유닛 테스트와 E2E 테스트를 같이 진행할 수 있습니다! 프론트만 테스트하실 거라면 굳이 jest와 나눠쓰지 않아도 됩니다.

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 테스트 도구에서도 다 확인이 가능하긴 합니다만 저런걸 확인하는 용도로는 상대적으로 무겁고 불편합니다. 때문에 여력이 되신다면 둘 다 하시는걸 추천하고 싶은데... 이게 쉽지가 않긴 하죠. ㅋ