FrontEngineer JungBam

프론트엔드에서의 테스트 코드 작성이다보니 렌더링 요소들에 대한 테스트를 주로 작성했다. 글이 작성 되었을때 작성이 되면 경로가 이동되거나 아니면 작성 버튼이 사라진다던가 같이.. 그러던 중 invalidateQuery와 동일하게 추가가되면 새로운 서버 데이터를 받아오는 모킹작업을 해볼까? 라는 생각이 들었다.(뭔가 깔끔한 테스트 코드가 될 것 같은..!?) react-query가 뭔지 모르고 invalidateQuery가 뭔지 모른다면 여기까지만 보시길.. 구글링을 해도 단순히 axios를 모킹해서 axios 호출에 대한 테스트를 진행하는 것뿐. 내가 원하는 성공하면 다시 get요청을 보내서 다시 렌더링해. 라는 로직이 구현될리 없었다. 그래서 서버가 돌아가는 원리가 결국에는 스택을 쌓는 것이기 때문에 ..

next.js에서 jest로 테스트를 하기 위한 초기 설정을 알아보자. 1. package.json 의존성에 아래 라이브러리 추가하고 npm install 하기 ** msw 는 서버 요청에 대한 모킹을 하기 위해 추가한 라이브러리 "@testing-library/jest-dom": "^5.16.5", "@testing-library/react": "^14.0.0", "jest": "^29.6.1", "jest-environment-jsdom": "^29.6.1", "msw": "^1.2.2", 2. root 폴더에 아래 두가지 설정 파일 추가 // jest.config.js const nextJest = require("next/jest"); const createJestConfig = nextJest(..

프론트 작업을 하다가 보면 mock data를 쓴다는 이야기를 테스트 코드를 접하지 않았더라도 들어봤을 것이다. 이 mocking 함수라는 것도 이 mock data와 동일한 개념으로 이해하면 편하다. 흔하게 mock data를 사용하는 경우는 어떤 경우에서의 반환되는 데이터를 간단하게 대체해서 UI를 구성하는 데에서 사용한다. 즉, 가짜 데이터를 이야기한다. 그런 측면에서 테스트 코드의 mocking도 동일하다. 즉 가짜 함수를 만들어서 반환되었을 때의 테스트를 진행한다고 생각하면 된다. mocking 함수, 즉 가짜 함수를 만들어서 그 값을 예상되는 반환값을 주도록 작성하고 그 값을 토대로 UI나 단위 테스트를 진행하는 것이다. 그럼 이 mocking 함수에 대해서 어떻게 호출하고 반환값은 어떻게 설..

이 부분에 대해서 공식문서 내용을 확인해보자. 공식문서 내용 :: 단일 요소 getBy...: 쿼리에 대해 일치하는 노드를 반환하고 일치하는 요소가 없거나 둘 이상의 일치가 발견되면 설명 오류를 발생시킵니다 ( getAllBy둘 이상의 요소가 예상되는 경우 대신 사용). queryBy...: 쿼리에 대해 일치하는 노드를 반환하고 null일치하는 요소가 없으면 반환합니다. 이는 존재하지 않는 요소를 어설션하는 데 유용합니다. 둘 이상의 일치 항목이 발견되면 오류가 발생합니다( queryAllBy정상인 경우 대신 사용). findBy...: 지정된 쿼리와 일치하는 요소가 발견되면 해결되는 Promise를 반환합니다. 요소가 발견되지 않거나 기본 시간 제한 1000ms 후에 둘 이상의 요소가 발견되면 약속이 ..

1. 무엇을 렌더링할것인가? 2. 프롭스가 필요한가? 3. wrapper가 필요한가?(Provider, Router 등) 4. 어떤 파일에서 테스트 할 것인가? 5. 어떻게 테스트할 것인가?(테스트 하는 기능들) 6. 비동기 처리가 필요한가? 좀 더 딥하게 생가하고 정리해보자! 1. 무엇을 렌더링할 것인가? 테스트 하고자 하는 기능을 갖고 있는 최소한의 컴포넌트를 render() 한다. 테스트하는 document가 render되는 컴포넌트라고 생각했을 때, 내가 테스트해야 하는 기능의 트리거만 있는 컴포넌트만을 렌더해서는 안된다는 것이다. ※ 초반에 테스트 코드를 짤때에 자주 했던 실수 중에 하나가 바로 이부분이었다. 2. 프롭스가 필요한가? 프롭스에 간단한 값이 필요하다면 값을 주면되지만, 콜백함수가 ..

Warning: An update to Option inside a test was not wrapped in act(...). When testing, code that causes React state updates should be wrapped into act(...): 비동기 처리에 대한 테스트를 하다가 보면 해당 경고를 만날 수 있다. 경고에서는 act()로 감싸주라는 내용인데 이 act를 감쌈으로써 내부 로직이 동작 한 후에 DOM요소에 적용된 상태에서의 테스트를 하도록 하는 것이다.(act의 활용방법은 아래 코드와 같다.) * act에 대해서 자세히 정리된 글이 있어 참조했다.(아래 링크) test('test', () => { act(() => { /* DOM에 반영하고 싶은 코드들 */ ..

userEvent는 클라이언트의 행동을 모방해서 테스트를 진행함에 따라 사용자의 인터렉션에 따른 결과를 테스트하기에 적합하다는 것은 지난 번 글을 통해 알 수 있었는데 그렇다면 어떻게 사용하는지 자세히 알아보자. 먼저 userEvent를 사용하기 위해서 아래 명령어를 통해 라이브러리를 설치한다. npm install --save-dev @testing-library/user-event @testing-library/dom 라이브러리 설치가 끝나면 사용할 스크립트에서 import!! import userEvent from '@testing-library/user-event' 1. click(element, eventInit, options) :: 클릭 userEvent는 유저의 인터렉션을 모방한다고 설명한..

지난 번 글에서 findby에 대해서 알아보았고 문서에 나오는 나머지 두가지 방법에 대해서 알아보자. 공식문서를 보고 싶다면 글 아래 링크 참조~ waitFor :: 비동기적 요청에 대한 결과를 기다렸다가 테스트하는 것. - 엥? findby도 그런 것 아니었나요? " findby는 원하는 하나의 값이 도출되면 그 값만을 토대로 테스트하지만 이 waitFor는 옵션에 따라서 대기를 했다가 테스트를 한다는 점에서 큰 차이가 있다." function waitFor( callback: () => T | Promise, options?: { container?: HTMLElement timeout?: number interval?: number onTimeout?: (error: Error) => Error m..