jest

컴포넌트들이 모여 어떠한 하나의 기능을 수행할 때, 서버 통신이 개입되는 경우가 많다. 이 때, 만약 백엔드 단에서 api가 덜 만들어졌거나 원하는 결과를 넘겨주지 않는다면 먼저 프론트 개발을 들어가기도 어렵고, 완성되지 않은 api를 요구하는 기능의 테스트를 건너뛸 수 밖에 없다.결국 서버 통신이 요구되는 어떠한 기능이 잘 돌아가는지 보장할 수도 없고, 추후에 추가하더라도 이미 다른 코드들이 많이 짜여져있는 상황인데 이 기능의 예상치 못한 버그로 인해 많은 코드를 고쳐야할 수도 있다. 이러한 상황을 방지하기 위해 nock과 같은 라이브러리도 있지만, 나는 MSW를 도입하기로 하였다. MSW란?  MSW는 API 요청을 가로채서 사전에 설정해둔 목업 데이터를 넘겨주도록 설정해 주는 도구이다.nock과 같..

나는 강의를 들으며 강의 내용을 내가 진행한 프로젝트에 적용해보기로 하였다. 해당 프로젝트는 Next를 활용해서 구현하였고, 적용을 위해 추가적인 세팅이 필요했다. jest.config.ts import type { Config } from "jest";import nextJest from "next/jest";const createJestConfig = nextJest({ dir: "./", // jest가 동작되는 기본 경로 설정});const config: Config = { preset: "ts-jest", // jest 설정에 기반이 되는 preset 등록 coverageProvider: "v8", // coverage 코드 추적을 위해 사용되는 provider 설정 testEnviron..

여기서 사용할 문법은 Jest, Cypress 둘 다 동일하지만 Jest가 터미널 로그 확인이 더 수월해서 Jest로 문법을 익혀보았다. 환경설정 yarn add -D jest @types/jest ts-jest jest-environment-jsdom @testing-library/react @testing-library/dom @testing-library/jest-dom 위와 같이 패키지 설치를 진행한다. jest.config.ts  위 파일을 하나 만든 후 module.exports = { preset: "ts-jest", testEnvironment: "jest-environment-jsdom",}; 위의 내용처럼 설정해준다.package.json 파일 내에 위 내용을 선언해주어도 동작하지만..

테스트코드를 입문하기 전, 대체 왜 사용할까에 대해 강의를 듣고 정리해보았다. 테스트 코드의 장점 1. 리팩토링 시 최소한의 통과 기준을 만들어낼 수 있음 프론트엔드 작업을 하다보면 리팩토링을 하게되는 경우가 많은데, 이 때 예기치 못한 부분에서 버그가 발생하는 등 이슈가 발생할 수 있다.이 때 테스트코드를 작성해 놓으면 우리가 작업한 후의 코드가 통과해야 하는 최소한의 기준을 세울 수 있다.즉, 우리의 코드 변경으로 인해 중요한 로직이 이상하게 동작하는 것을 배포하기 전에 발견할 수 있을 것이다! 2. 문서화에 용이함 describe("회원가입 페이지", () => { /* 각 항목을 jira ticket으로 생각하고 작업할 수 있음 브랜치 별로 테스트코드 작업 가능 */ test("인풋이 활성화되..