Query 사용 우선순위 이 전 글들에서는 getByTestId 쿼리를 사용해 테스트를 진행했지만 사실 getByTestId는 testing-library에서 우선순위가 가장 낮은 쿼리입니다. 때문에 testing-library에서 권장하는 Query들의 우선순위를 살펴보고 가겠습니다. 기본 원칙에 따라 테스트는 사용자가 코드(컴포넌트, 페이지 등)와 상호 작용하는 방식과 최대한 유사해야 합니다. 이를 염두에 두고 다음과 같은 우선순위를 권장합니다: 1. 모든 사용자가 접근할 수 있는 쿼리(Queries Accessible to Everyone) Query 사용 우선순위가 가장 높은 것은 시각/마우스 사용자뿐만 아니라 보조 기술을 사용하는 사용자의 경험을 반영하는 쿼리입니다. getByRole: 이 쿼리..
Test Driven Development 란 무엇인가요? 실제 코드를 작성하기 전에 테스트 코드를 먼저 작성합니다. 테스트 코드를 작성한 후 그 테스트 코드를 Pass 할 수 있는 실제 코드를 작성합니다 TDD를 하면 좋은 점 TDD를 하므로 인해 많은 기능을 테스트하기에 소스 코드에 안정감이 부여됩니다. 실제 개발하면서 많은 시간이 소요되는 부분은 디버깅 부분이기에 TDD를 사용하면 디버깅 시간이 줄어들고 실제 개발 시간도 줄어듭니다. 소스 코드 하나하나를 더욱 신중하게 짤 수 있기 때문에 깨끗한 코드가 나올 확률이 높습니다. TDD 방식으로 카운터 버튼 앱 만들어보기 1. 해야 할 일 - 카운터는 0 부터 시작해야 됩니다. 2. 테스트 코드 작성 import React from "react"; im..
Rust 컴파일러에서 Jest 설치 방법 Next.js 12 릴리스부터 Next.js에는 이제 Jest를 위한 구성이 기본으로 제공됩니다. Jest를 설정하려면 jest, jest-environment-jsdom, @testing-library/react, @testing-library/jest-dom을 설치하세요: yarn add jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom -D 내부적으로 next/jest는 다음을 포함하여 자동으로 Jest를 구성합니다: SWC를 사용한 트랜스폼 설정 스타일시트(. css,. module.css 및 해당 scss 변형), 이미지 import 및 next/font 자동 mock..
해당 글은 John Ahn 님의 따라하는 리액트테스트 강의를 참고하여 작성했습니다. 왜 애플리케이션을 TEST 해야 할까요? 간단하게 더 안정적인 애플리케이션을 위해서는 여러 방법으로 테스트를 해줘야 더 안정적인 애플리케이션이 될 수 있습니다. 테스팅으로 얻는 이점은 무엇일까요? 디버깅 시간을 단축! 만약 데이터가 잘못 나왔다면 그것이 UI의 문제인지 DB의 문제인지등 전부 테스트를 해봐서 찾아야 하는데 테스팅 환경이 구축된 어있다면 자동화된 유닛 테스팅으로 특정 버그를 쉽게 찾아낼 수 있습니다. 더욱 안정적인 애플리케이션! 많은 테스트 코드와 함께 작성된 코드의 애플리케이션이 되기 때문에 훨씬 안정적인 애플리케이션이 됩니다. 이밖에도 재설계 시간의 단축과 추가로 무언가를 더 구현해야 할 때 더 용이하게..
미들웨어는 요청이 완료되기 전에 코드를 실행할 수 있게 해줍니다. 그런 다음 들어오는 요청에 따라 응답을 수정할 수 있습니다. 응답을 다시 작성하거나 리다이렉트하거나 요청 또는 응답 헤더를 수정하거나 직접 응답하는 등의 작업을 수행할 수 있습니다. 미들웨어는 캐시된 콘텐츠와 라우트가 일치하기 전에 실행됩니다. 자세한 내용은 '매칭 경로(Matching Paths)'를 참조하십시오. Convention 프로젝트의 루트에 있는 'middleware.ts' (또는 .js) 파일을 사용하여 미들웨어를 정의하세요. 예를 들어, pages 디텍터리 또는 app디렉터리와 동일한 수준이거나 src 내부에 해당되는경우 위치시킬 수 있습니다. Example /* middleware.ts */ import { NextRes..
라우터 핸들러를 사용하면 웹 요청 및 응답 API를 사용하여 지정된 경로에 대한 custom request handler를 만들 수 있습니다. 라우트 핸들러는 app 디렉터리 내에서만 사용할 수 있습니다. 이는 pages 디렉터리 내의 API 라우트와 동일한 역할을 담당하기 때문에 API 라우트와 라우트 핸들러를 함께 사용할 필요가 없다는 것을 의미합니다. Convention 라우트 핸들러는 앱 디렉토리 내의 route.js|ts 파일에 정의됩니다. /* app/api/route.ts */ export async function GET(request: Request) {} 라우트 핸들러는 page.js 및 layout.js와 유사하게 앱 디렉터리 내에서 중첩될 수 있습니다. 그러나 page.js와 동일한..
라우트 가로채기는 현재 레이아웃 안에서 라우트를 로드하면서 현재 페이지의 컨텍스트를 유지할 수 있게 해줍니다. 이러한 라우팅 패러다임은 특정 경로를 "가로채서" 다른 경로를 표시하고 싶을 때 유용합니다. 예를 들어, feed 내부에서 사진을 클릭할 때 feed 위에 모달이 나타나야 합니다. 이 경우, Next.js는 /feed 경로를 가로채고 이 URL을 /photo/123 대신에 보여줍니다. 그러나 공유 가능한 URL을 클릭하거나 페이지를 새로고침하는 경우와 같이 사진에 직접 이동할 때는 모달 대신 전체 사진 페이지가 렌더링되어야 합니다. Convention 라우트 가로채기는 (..) 구문을 사용하여 정의할 수 있습니다. 이는 상대 경로 표기법인 ../과 유사하지만 세그먼트에 대해 적용됩니다. 다음을 ..
병렬 라우팅(Parallel Routing)은 동시에 또는 조건에 따라 동일한 레이아웃에서 하나 이상의 페이지를 렌더링할 수 있게 해줍니다. 대시보드나 소셜 사이트의 피드와 같은 매우 동적인 앱 섹션에서는 병렬 라우팅을 사용하여 복잡한 라우팅 패턴을 구현할 수 있습니다. 예를 들어, @team 페이지와 @analytics 페이지를 동시에 렌더링할 수 있습니다. 병렬 라우팅을 사용하면 독립적으로 스트리밍되는 각 경로에 대해 독립적인 오류 및 로드 상태를 정의할 수 있습니다. 병렬 라우팅은 인증 상태와 같은 특정 조건에 따라 슬롯을 조건부로 렌더링할 수 있도록 해줍니다. 이를 통해 동일한 URL에서 완전히 분리된 코드를 사용할 수 있게 됩니다. Convention 병렬 라우트는 명명된 슬롯(named slo..
