프론트엔드, 어떤 것을 테스트해야 할까요?

프론트엔드 코드에 대한 테스트를 작성하시는데 어려움이 있으시군요. 말씀하신데로 프론트엔드 애플리케이션을 제대로 테스트하려고 하면 생각했던 것보다 쉽지 않다는 것을 느끼시게 됩니다. 주로 입력과 출력이 명확한 함수나 클래스로 이루어진 백엔드 코드에 비해서, 프런트엔드 테스팅은 좀 더 난이도가 있는 편이에요. 그래서 프런트엔드 쪽 개발 경험이 많지 않으시다면 어렵게 느껴지시는 게 매우 자연스러운 일입니다. 프론트엔드 테스팅에 접근하실 때는 우선 UI와 비즈니스 로직을 구분해서 생각하시는 게 좋아요. 대부분의 비즈니스 로직은 백엔드에 있겠지만 그래도 프론트엔드에도 여러 이유로 일부 비즈니스 로직이 있을 수 있거든요. 이러한 프런트엔드 단 비즈니스 로직은 백엔드 코드를 테스트하는 것과 크게 다르지 않습니다. 함수나 클래스의 메서드에 어떤 인자로 어떤 값을 넘기면 어떤 값이 반환되는지 테스트를 하시면 되고요. React로 개발한다고 하시니 비지니스 로직은 React 훅(hook)을 통해 컴포넌트로 부터 분리되어 있을 것 같은데요. 그럼 각 훅 함수에 대한 테스트 작성이 필요하다고 생각하시면 될 것 같습니다. UI 테스트는 좀 더 복잡해지는데요. 우선 각 컴포넌트가 최초에 랜더링이 될 때 브라우저 화면에 무엇이 나타나야 하는지를 테스트하셔야 합니다. 예를 들어, 상품 상세 정보를 보여주는 컴포넌트라고 하면 상품의 제목, 설명, 이미지, 가격 등등이 알맞은 HTML 요소 안에서 나타나는지를 테스트하셔야 할 거에요. 그리고 사용자의 행위(마우스 클릭, 키보드 입력, 등등)에 반응하는 컴포넌트의 경우, 해당 컴포넌트가 사용자와 예상한대로 상호작용하는지도 테스트를 해주셔야 되는데요. 예를 들어, 장바구니 컴포넌트라면 어떤 아이템을 상대로 수량 더하기나 빼기 버튼을 눌렀을 때, 변경된 수량에 따라서 합계 금액 부분이 다시 계산되어 랜더링이 되는지를 테스트해주셔야 겠네요. 마지막으로 프론트엔드 코드에 대한 테스트를 작성할 때는 라이브러리를 잘 선택해서 쓰시는 게 상당히 중요합니다. React 쪽에서는 RTL(React Tesing Library)가 아주 많이 쓰이고 있어요. 이 라이브러리를 만드신 분이 Kent C. Dodds라고 React와 프론트엔드 테스팅 쪽에서는 엄청난 선구자이시거든요. 그래서 이 분이 만드신 라이브러리 자체를 공부하는 것만으로도 프론트엔드 테스팅을 어떻게 해야하는지 정말 많이 배울 수가 있어요. RTL에 대해서는 제가 관련해서 예전에 블로그에 올려놓은 포스팅이 있어서 공유드릴테니 한번 참고해보세요. - React Testing Library 사용법: https://www.daleseo.com/react-testing-library/ - React Testing Library - 비동기 테스트: https://www.daleseo.com/react-testing-library-async/ - React Hooks Testing Library 사용법: https://www.daleseo.com/react-hooks-testing-library/ - 유저 이벤트 테스트 (@testing-library/user-event): https://www.daleseo.com/testing-library-user-agent/ 레거시 코드라고 하시니 추가적으로 조언 하나만 더 드리면 이미 그렇게 하려고 생각하고 계신 것 같지만 시간이 좀 걸리시더라도 테스트를 최대한 꼼꼼이 많이 작성하시고 리팩터링을 진행하시라고 말씀드리고 싶어요. 이 과정이 좀 고통스러울 수도 있지만 해당 컴포넌트가 어떤 일을 하고 어떻게 동작하는지를 이해하는데 테스트를 작성하는 것만큼 좋은 방법도 없거든요. 우선 해당 레거시 컴포넌트가 브라우저 화면에 무엇을 그리는지를 잘 관찰하시고 그에 대한 테스트를 작성하세요. 그러면 혹시 리팩터링을 하시다가 기존에 그리던 게 안 그려지게 되면 바로 테스트가 실패할 수 있게요. 그 다음에는 해당 컴포넌트 내에서 버튼이나 입력란 같은 사용자와 상호작용하는 부분을 찾아보세요. 그리고 그 녀석들을 상대로 사용자 이벤트를 발생시켰을 때 화면에서 일어나야 변화에 대한 테스트를 작성하세요. 그러면 혹시 기능 추가를 하시다가 기존에 일어나던 상호작용이 발생하지 않으면 테스트가 실패하게 될 겁니다. 이런 식으로 테스트 커버리지를 조금씩 높여가면서 리팩터링 및 기능 추가를 안전하고 효과적으로 수행할 수 있습니다. 좋은 의도로 리팩터링하셨는데 혹시 제품에 문제가 생기면 괜히 욕만 먹고 속상한 일이 생기실까봐 쓰다보니 답변이 너무 길어졌네요. 아무튼 기능 추가만 하시려는 게 아니라 리팩터링까지 고려하시는 게 개발자로서 너무 바람직한 자세이십니다. 그럼 부디 좋은 결과 있으시길 바랍니다!

한번에 다 만들려고 하지 말고 코드가 작은 것부터 추가 하는 것을 권장합니다. 그리고 새로운 코드는 테스트도 같이 들어간다고 생각해야하는데 문제는 테스트 추가 대한 공감대가 있어야겠지요. 공식적으로 테스트 코드 작성에 대한 승인을 받으면 더 여유롭게 할 수 있겠죠 ui 통합 test도 하면 좋겠지만 unit 테스트 부터 해보세요. 해보시면 비동기 작업이 들어간 코드들이 테스트하기 까다롭습니다… 어떤 글에는 프론트에서 상세(unit) 테스트는 필요없다던가 하는 의견도 있고 검색해보면 여러 글이 많아서 읽어보고 상황에 비추어 생각해보셔야할 듯 합니다

저는 프론트에서 테스트는 백엔드에서의 테스트와는 조금은 다르다고 생각해요. 1. 디자인 변경에 따라서 너무 코드가 자주 바뀝니다. 한 번 작성한 코드가 오래 사용되는 경우가 잘 없어요. 테스트코드도 같이 쓸모가 없어지는 경우가 많습니다. 2. 그래서 디자인과 비지니스로직 분리가 중요합니다. 3. 저는 주로 edge케이스가 될 수 있는 상황에서의 integration test를 주로 작성합니다. 특정 조건을 만족해야만 나오는 ui의 경우 QA에서 잘 못잡기 때문에, user가 특정 role을 가질때나, api에서 특정 에러코드가 내려온다거나 하는 경우에 작성합니다. 4. 테스트 커버리지는 중요하게 생각하지 않습니다. 특정 component에 대한 unit test는 거의 작성하지 않습니다.