프론트엔드 프로젝트에 테스트를 적용하면서 가장 어렵게 느껴진 부분이 어떤 순서로, 무엇을 테스트하면 좋을지에 관한 것이었습니다. 이에 대해 Kent C. Dodds와 Tkdodo님의 블로그를 참고하여 이에 대한 생각을 정리해 보았습니다. 🤔 어떤 순서로, 무엇을 테스트할까? 테스트를 작성하는 목적 가운데 하나는 사용자, 즉 애플리케이션 사용자와 개발자가 애플리케이션을 사용할 때 애플리케이션이 제대로 동작할 것이라는 자신감을 주는 것입니다. 따라서 코드 커버리지 자체보다는 유저가 사용하는 유즈 케이스 모두를 코드가 지원하는지를 생각해보면 좋습니다. 무엇을 테스트하면 좋을까? React에서는 어떠한 유즈 케이스가 있을까요? 크게 아래의 3가지 경우를 생각해 볼 수 있습니다. 라이프사이클 메서드: rerend..
크롬 개발자 도구 사용 중에 실수로 불편을 겪을 수 있는 문제라고 생각되어 공유하게 되었습니다. 문제 상황 리액트 애플리케이션이 잘 동작하는데 리로드만 하면 자꾸 react-dev-tools에서 다음과 같은 에러가 발생하며 페이지가 무한 로딩 되는 문제가 있었습니다. Looks like this page doesn't have React, or it hasn't been loaded yet 그리고 네트워크 탭을 확인했을 때 아래와 같이 스크립트 로드가 실패하는 것을 확인할 수 있었습니다. 분명히 리액트로 만들어진 페이지고, DevTools를 끄면 잘 동작하는데 왜 이런 걸까요..? 해결 스택오버플로우의 이 글에 따르면 크롬 DevTools 디버거가 breakpoints에서 멈추는 경우 페이지를 리로드 하..
이전에 React Query meets React Router라는 글을 읽고 데이터를 효율적으로 가져올 수 있는 방법이라고 생각되어 노션에 정리해 두었는데, 최근 사용자 경험을 개선하는 작업을 하면서 적용해 보았습니다. 이 과정에서 알게 된 내용과 고민했던 지점들을 공유하려고 합니다. Preloading? Prefetching? 필요한 리소스를 미리 다운로드한다는 의미에서 preload와 prefetch가 헷갈릴 수 있다고 생각되어 먼저 알아보겠습니다. 브라우저의 리소스 로드 우선순위 지정 유형 가운데 link 태그의 preload와 prefetch를 살펴보겠습니다. preload는 현재 페이지에서 즉시 필요로 하는 리소스를 우선적으로 가져오는 작업입니다. 이 리소스는 브라우저의 주요 렌더링 절차 이전..
현재 참여하고 있는 글또에서 코드트리와 협업하게 되어 8주간 체험할 수 있는 정말 좋은 기회를 가지게 되었습니다. 한 달간 매일은 아니지만 꾸준히 1~3문제 정도를 풀면서 느꼈던 점들을 작성해 보겠습니다. 코드트리 전의 알고리즘 공부이전에는 주로 백준의 추천 문제집 또는 프로그래머스의 고난도 문제집을 풀었습니다. 이 과정에서 분명히 느는 부분이 있었지만, 문제가 풀리지 않거나 해설을 봐도 이해가 되지 않으면 막막할 때가 많았습니다. 많은 분들이 문제를 많이 풀어보는 게 답이라는데, 문제를 꾸준히 풀어나가기 어려운 부분들이 있었던 것 같습니다. 코드트리 어땠나요?1. 체계적 학습을 통한 “나도 할 수 있다”는 느낌무엇보다 가장 좋았던 점은 어려운 문제를 바로 맞닥뜨리는 것이 아니라 기본 개념부터 연습 문제..
기능 구현이 끝난 후 프론트엔드 성능이 사용자 경험에 영향을 미칠 수 있다는 것을 알고, 서비스의 품질 향상을 위해 LightHouse와 번들 분석기를 이용해 성능 지표를 측정하며 개선하고자 했습니다. LightHouse를 통해 성능을 측정하였을 때, FCP와 LCP 지표가 낮게 나온 것을 확인하였고, 이를 개선하였습니다. 먼저 해당 지표들의 의미를 알아보고, 개선점을 살펴보겠습니다. FCP와 LCP FCP(First Contetnful Paint)는 유저가 페이지에 처음 진입했을 때, 콘텐츠가 처음 렌더되기 시작하는 시점을 뜻합니다. 즉, 페이지 콘텐츠가 모두 렌더 되지 않아도 일부가 렌더 되기 시작했다면, 이 시점을 측정합니다. 이때 콘텐츠는 이미지나 텍스트, 요소, 내용이 있는 요소를 뜻합니다. 이..
회원 가입과 로그인 폼에서 공통으로 사용하고 있는 Input 컴포넌트의 props 타입을 지정하는 과정에서 제네릭을 활용하는 방법을 공유하고자 합니다. React-hook-form을 사용하면서 저처럼 타입 지정에 어려움을 겪으신 분들에게 도움이 되면 좋겠습니다. 우선, 제네릭에 대해 간단하게 알아보고, 코드를 보면서 작성해 나가겠습니다. 제네릭 타입개념제네릭은 말 그대로 일반화된 데이터 타입으로, 함수, 타입, 클래스 등에서 사용할 타입을 미리 정해두지 않고, 타입 변수를 사용해 해당 위치를 비워둔 다음, 실제로 그 값을 사용할 때 외부에서 타입 변수 자리에 타입을 지정하여 사용하는 방식입니다. 들어올 수 있는 여러 타입을 일일이 지정해주지 않아도 되기 때문에 재사용성이 크게 향상된다는 장점이 있습니다...
✅ 들어가기 전 테스트를 왜 작성하는가? 에 대해 다시 생각해 보기 요구 사항 분석과 철저한 이해 → 코드 설계 사용자 입장에서 코드를 작성 → 내부 구현보다는 인터페이스 위주의 코드 작성 TDD의 본질은 빠른 피드백 TDD는 아니지만, 각 컴포넌트가 수행하기를 기대했던 동작, 즉 요구 사항을 다시 생각해 보고, 테스트를 작성하자. 🤔 고민 폴더 구조 루트에 mocks, tests 폴더를 두고 내부에 프로젝트 구조 폴더를 나누기 ✅ 각 폴더 내부에 mocks, tests 폴더 → 관련 있는 코드 가까이 두는 것이 유지보수 측면에 좋을 것으로 판단 깃허브에서 React, React Query, MSW, RTL, Vitest 등에서 테스트 폴더 구조를 살펴봤을 때 각 관련된 폴더 내부에 tests 폴더를 따..
들어가며 [1편]에서 테스트 환경 구축 시 사용되는 패키지의 설정 파일을 살펴보았습니다. [2편]에서는 먼저 Vite, TypeScript, React Testing Library, Jest를 사용해 테스트 환경을 구축하고, 패키지 간 의존성과 설정 파일 문제로 발생했던 에러와 해결책을 공유하고자 합니다. React 테스트 환경 구축하기(Vite, TS, Jest, React Testing Library) Vite 프로젝트 설치 npm create vite@latest test-config -- --template react-ts cd test-config npm install code . // vscode 열기 테스트 관련 패키지 설치 // 2-1 Jest 관련 패키지 설치 npm i -D jest j..
