코드와 함께 살펴보는 프론트엔드 단위 테스트 – Part 1. 이론 편“테스트 코드 작성은 파일을 만들어서 한 글자 쓰기 전까지 엄청 귀찮다.” from 언젠가 내가 데일리 스크럼에서 한 말개발자들에게 테스트 코드 작성은 해야 하지만 손이 잘 가지 않는 숙제 같은 일입니다. 테스트 코드를 쓰면 쓸수록 귀찮다고 얘기하는 분도 본 것 같습니다. (ㅋㅋㅋㅋ) 그럼에도 테스트의 중요성을 부정하는 개발자분은 없을 것으로 생각하는데요. 클린코드, 리팩터링을 비롯한 많은 개발 서적에서도 테스트 코드의 중요성을 강조하고 필요하다고 이야기하고 있습니다. TDD(Test Driven Development)에서는 아예 테스트 코드를 먼저 만들고 본 코드를 작성하라고 이야기하고 있습니다. 최근 몇 년간 프론트엔드에서 다루는 영역이 늘어나면서 코드의 복잡성도 올라가고 예전보다 많은 비즈니스 로직을 프론트엔드에서 다루게 되었습니다. 이와 함께 프론트엔드의 품질과 테스트에 대한 관심과 중요성도 함께 올라가는 것 같은데요. 예전에는 프론트엔드 개발자에게 테스트에 대한 역량이 경쟁력이었다면 요즘은 서서히 필수 역량이 되어가는 것 같기도 합니다.이번 글에서는 테스트 코드 중에서도 단위 테스트에 집중해 프론트엔드 코드와 함께 살펴볼 예정입니다. 총 두 편으로 구성했으며 "Part 1. 이론 편"에서는 단위 테스트에 대한 간략한 소개와 효과적인 단위 테스트 코드 작성을 위해 신경 쓰면 좋은 부분, 그리고 테스트 코드가 코드 개발에 어떤 도움을 줄 수 있는지까지 다루어 보겠습니다.프론트엔드는 여전히 많은 분야가 불모지이고 테스트도 그중 하나입니다. 하지만 많은 개발자의 고민과 노력으로 매년 다양한 라이브러리가 나오고 있습니다. 테스트 종류에도 오늘 이야기하는 단위 테스트 말고도 스냅샷 테스트, e2e 테스트 등 다양하게 존재합니다. 테스트는 기본적으로 무언가를 검증하고 확인하는 용도로 만드는 것이므로 어떤 것을 확인할 것인가에 따라 적용하는 테스트 종류가 다릅니다.단위 테스트는 특정한 모듈 혹은 단위가 기능을 의도한 대로 올바르게 수행하고 있는지 확인하는 것으로, 테스트 중에서도 가장 기본이고 기저에 깔려 있어야 하는 테스트입니다. 특정 모듈이나 단위라는 단어가 의미하는 것처럼 단위 테스트는 범위가 한정적이므로 각 단위에 대한 테스트 코드의 양이 적고 효율적입니다. 하지만 명세가 변경된다면 가장 많이 영향을 받는 테스트이기도 하니 설계에 신중해야 합니다.테스트 코드는 말 그대로 프로덕트와 코드가 올바르게 동작하고 기능하는지를 테스트하는 코드입니다. 즉, 코드가 올바르게 작성되었는지 검증하는 또 다른 코드라는 이야기입니다. 테스트 코드는 프로덕트의 안정성과 유지 보수성 향상에 기여하는 코드로 대충 쓰는 것이 아닌 잘 작성하려는 노력이 필요합니다. 테스트 코드 역시 한 번 만들고 끝이 아니라 프로덕트를 구성하는 코드처럼 계속 유지 보수되고 발전시켜야 합니다. 지금부터는 테스트 코드 작성에 앞서 좋은 테스트 코드를 작성하기 위해 알아야 할 혹은 도움이 될만한 내용을 소개하겠습니다

최근에는 FE에도 jest, cypress와 같은 훌륭한 테스트 도구들이 등장하면서, 효율적으로 통합 테스트나 e2e 테스트를 작성할 수 있게 되었습니다. 하지만 테스트를 작성하다 보면 더미 데이터를 만들거나 많은 API를 모킹해가며 테스트를 진행해야 하는 것은 변함이 없었습니다. 그리고 이것은 꽤나 많은 비용을 발생시키는 작업이었습니다. 오늘은 이런 문제를 해결하기 위해 MSW(Mock Service Worker)라는 도구를 통합테스트에 도입하게 된 경험과 테스트에서 어떻게 활용할 수 있는지 소개해 드리려 합니다. 해당 글은 react(typescript), jest(testing-library)를 기반하여 작성되었음을 알려드립니다. MSW의 도입 들어가기에 앞서 Front-End에서 작성하고 있는 보편적인 테스트들을 알아보겠습니다. 대표적으로 유틸 함수를 테스트하거나 작은 단위의 컴포넌트를 테스트하는 코드들이 있을 것입니다.

최근 협업 도구인 Dooray! 개발을 담당했었다. 두레이에서는 현재 웹 리뉴얼 작업과 함께 타입스크립트와 리액트 프레임워크로의 전환을 진행하고 있다. 이 과정에서 사용하게 된 커스텀 훅과 이를 테스트 라이브러리인 testing-library를 사용해서 테스트하는 방법을 알아보자. 리액트 훅은 2018년 말 React 16.8에 추가되었다. 리액트 훅을 사용해서 상태 값과 여러 리액트의 기능을 사용할 수 있다. 이전부터 리액트를 사용해 왔다면 render props와 고차 컴포넌트와 같은 패턴을 통해 문제를 해결할 수 있지만 이런 패턴의 사용은 컴포넌트의 재구성을 강요하며, 코드의 추적을 어렵게 만든다. 리액트 훅을 사용하면 컴포넌트로부터 상태 관련 로직을 추상화 할 수 있다. 이를 이용해 독립적인 테스트와 재사용이 가능하다. 또한 리액트 훅을 사용할 때는 몇 가지 규칙이 있다. 반복문, 조건문 혹은 중첩된 함수 내에서 훅을 호출하지 마라. 오직 리액트 함수 내에서만 훅을 호출해야 한다. 여기서 2번 규칙을 지키기 위해 일반적인 자바스크립트 함수에서 리액트 훅을 호출하지 말고 리액트 함수 컴포넌트 또는 커스텀 훅을 통해서 훅을 호출할 수 있다. 이 글에서는 리액트 커스텀 훅을 작성하는 방법과 훅 테스트를 작성하는 방법에 대해서 설명한다. 리액트 훅에 대한 더 자세한 설명은 리액트 훅 공식문서를 참고하자. 테스트할 리액트 커스텀 훅 필자는 여러 컴포넌트에서 중복해서 사용되는 로직을 공유하기 위해서 커스텀 훅을 사용했다. 다음의 예시를 살펴보자. import { useEffect, useState } from 'react'; import Page from '@common/types/page'; type PageMap = { [id in string]?: Page }; const CachePageMap: PageMap = {}; export const DEFAULT_PAGE: Page = { }; const usePage = (pageId: string, defaultPage = DEFAULT_PAGE) => { const [data, setData] = useState<Page>(defaultPage); const [isLoading, setLoading] = useState(true); useEffect(() => { const cacheID = pageId; const cachePage = CachePageMap[cacheID]; if (cachePage !== undefined) { setData(cachePage); setLoading(false); } else { setLoading(true); setData(defaultPage); } const url = `/get-page/${pageId}`; fetch(url) .then((res) => res.json()) .then((newData) => { CachePageMap[cacheID] = newData.data; setData(newData.data); setLoading(

프론트엔드 테스트 팁개요안녕하세요 벌써 병역특례 3년차! 곧 민간인이 되는 Integration Engineering 팀 윌리입니다! 본격적으로 글을 읽으시기 전에 어떤 내용인지 이 글의 성격을 알려드리려 합니다.대상비즈레버 프론트개발에 대해 궁금하신 분, 왜 다양한 프론트 테스트가 필요한지 궁금하신 분, 리액트 컴포넌트를 유닛테스트할 때 swr 때문에 고생하시는 분이 이 글을 읽으실 때 더 좋은 정보를 얻으실 것 같습니다.유닛, 통합 테스트 팁 챕터는 개발자를 대상으로 기본적인 react, javascript, typescript에 대해 알고 있는 사람을 가정하고 작성했습니다.목차는 아래와 같습니다.목차테스트의 종류 비즈레버 프론트는 어떤 테스트를 하나? 유닛, 통합 테스트 팁 테스트 라이브러리와 기초 컴포넌트 테스트 React Hook, SWR Hook 함수 테스트 타이머가 있는 경우 Hook을 쓰는 페이지 테스트 (통합 테스트) 후기: 완벽한 테스트를 위해테스트의 종류테스트의 종류타입이나 컨벤션을 잡는 정적 테스트를 제외하고 일반적으로 소프트웨어 개발에서 이야기하는 테스트는 보통 3가지를 말합니다.unit test , integration test , e2e(end to end) test 입니다.만약에 테스트에 대한 지식이 없으신 분은 차례대로 더 포괄적이고 큰 범위의 테스트를 한다 생각하시면 이해에 도움이 됩니다.저는 3가지 테스트를 게임 스타크래프트의 저그 종족에 비유하고 싶습니다. 초보인 상대를 이기기 위해서는 저글링, 히드라, 뮤탈 유닛 중 하나만 잘 사용해도 승리할 수 있지만, 중수 이상의 실력자는 3가지 유닛을 한 게임에 다 사용해야 게임에서 이길 수 있습니다.테스트도 다양한 유닛을 활용하는 저그처럼 필요에 따라 다양하게 방법을 채용하면 소프트웨어 품질을 더 잘 보증 할 수 있다고 생각합니다.unitunit은 유닛테스트, 단위테스트라고 많이들 말씀하시는데 코드에서 가장 작은 한 묶음인 함수, 클래스같은 모듈을 테스트하고 프론트엔드에서는 파일구조를 컨테이너/컴포넌트로 나눌 때 컴포넌트에 해당되는 파일에 테스트를 작성하면 유닛테스트로 봅니다. 저그 종족에서 안 뽑을 수 없는 저글링처럼 가장 기본적인 단위 테스트입니다.integrationintegration, 통합테스트는 여러 모듈끼리 연결이 있는 코드를 테스트합니다. 객체끼리 데이터를 주고받고 여러 모듈을 핸들링하는 코드의 테스트 통합테스트로 보면 됩니다. 프론트엔드에서는 파일구조를 컨테이너/컴포넌트로 나눌 때 컨테이너에 해당하는, 즉 페이지 자체를 테스트하는 코드를 짜면 여기에 해당된다 볼 수 있습니다.예를 들면 아래 같은 테스트입니다.api를 패칭 값에 따라 원하는 컴포넌트를 뿌려주고 상호작용이 잘 되는지 확인한다.e2ee2e 테스트는 end to end의 줄임말로 모듈, 코드 입장에서 품질을 보증하던 위 2가지 방법과 다르게 코드를 통해 사용자 입장에서 테스트하는 방법을 말합니다. 예시로 들면 Cypress, Selenium 같은 툴로 실제 사용자처럼 개발 환경으로 구