Front-end Test

JavaScript 테스트 프레임워크 (testing 도구)중점 대규모 웹 응용 프로그램에 대한 단순성과 지원 장점zero configuration 철학 으로 (별도의 설정 없이) 빠른 테스트 케이스 작성 가능현재 가장 많이 사용됨제작유지 관리 : Meta (구 F

Jest | Basics 1 (소개 / 설치 / 간단한 Test)설치 방법‘예시 | 간단한 Test’의 ‘1. fn.js 제작’객체 인스턴스의 모든 속성을 재귀적으로 비교 ("deep" equality 라고도 함).toBe 와 비슷하게 사용 가능toEqual(), to

test함수에 콜백 함수를 전달하지 않았을 경우3초(3000ms) 이상 걸려야 하는데 바로 통과(1ms)되고 종료3초 후에 이름을 알려주는 함수 작성 (fn.js)사용하는 코드 작성 (fn.test.js)테스트npm test결과 확인테스트 하니, 바로 통과실패하는 코드

테스트를 작성하다보면 테스트 전후에 해줘야될 작업들이 생김. → 이런 처리 가능 하도록 Jest는 help 함수 제공 > 🔍 테스트 방법 npm test 🔍 공통 사항 [옵션] timeout(milliseconds) 사용 가능 기본 timeout : 5초 → 해당: beforeEach/All, afterEach/All, only �...

테스트 하기 위해 흉내만 내는 함수즉, 실제 함수를 구현한 것이 아니라 그저 흉내만 낸, 테스트 하기 위해서 만든 일종의 모형mock 의 사전적 의미 모의의, 가짜의 mock up 의 사전적 의미 모형, 모의 어떤 작업을 테스트 할 때, 목 함수로 간단히 테스트

npm test 또는 npm test aCreate React App으로컴포넌트 제작 (src/component/Hello.js)컴포넌트 import (src/App.js)불필요한 코드 제거Hello 컴포넌트 import화면잘 보임 (Hello)user 제작 후, 전달

Warning: ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it's

직접 여러 공통 컴포넌트를 구현했다면 반드시 핵심 기능들을 단위 테스트로 검증해야 함. 다른 도구(ex. 스토리북)를 통해 검증모든 컴포넌트, 즉 커버리지 100%를 위한 단위 테스트는 작성 및 유지 보수 비용이 선형적으로 증가할 뿐임.의미 無JS DOM에서 DOM

검증하지 않아도 되는 것의존성의 동작 같은 것 범용적인 라이브러리(ex. react, react-router-dom)는 이미 내부적으로 상세히 핵심 기능을 단위 통합 테스트로 검증한 상태 → 우리가 useNavigate를 사용하는 컴포넌트의 단위 테스트에서 useN

독립적인 단위 테스트를 작성하기 좋은 케이스 React Testing Library을 사용하면 별도의 Hook으로 추상한 로직들의 상태가 올바르게 변경되는지 손쉽게 검증 가능 기능 모달의 Open 상태에 대한 로직 처리 단위 테스트로 검증하는 이유안정성을 위해

사용하는 경우 대량의 이벤트 핸들러(ex. 스크롤)가 발생할 때 성능 개선 목적 디바운스 함수의 구현 특정 시간에 따라 함수의 호출 여부를 판단하기 위해 내부적으로 타이머 SetTimeout과 ClearTimeout을 사용하여 호출 횟수를 제한 1번째 테스트 (

클릭 이벤트를 발생시키는 경우순수 JS 코드로 표현하면 MouseEvent 인스턴스를 만들어 디스패치하는 것과 거의 유사 이 경우가능한 것 클릭 이벤트에 대한 제어, 캡처링, 버블링만 가능 불가한 것 (실제 사용자가 사용할 때처럼) 다양한 이벤트들이 시뮬레이션

앱의 전반적인 기능을 테스트 하기 위한 대안들참고실무에 바로 적용하는 프런트엔드 테스트

기능 단일 모듈 또는 컴포넌트를 전체 애플리케이션에서 떼어내어 분리된 환경에서 테스트 장점 해당 모듈의 기능을 세밀하고 빠르게 검증 가능 단점 (특정 모듈만 독립적으로 검증함 →) 여러 모듈이 실제로 잘 연결되어 올바르게 동작하는지는 검증 못 함. 여러 개의

대상 : 테스트 범위에 대한 큰 고민 없이 검증할 수 있는 단순한 것들그렇기 때문에 거대한 책임으로 구성된 비즈니스 로직을 나누어 컴포넌트 집합을 구성하고 이 컴포넌트 집합을 하나의 통합 테스트 단위로 선정하여 테스트 코드를 작성하게 됨상품 목록을 보여줌상품명 or 카

통합 테스트는 주로 API를 통해 가져온 데이터나 앱에서 사용하는 상태를 기준으로 비즈니스 로직을 검증함.파일 설명state로 관리하는 것 : 장바구니에 담긴 상품에 대한 정보와 총 수량, 가격액션 : 액션(ex. addCartItem, removeCartItem, r

장바구니의 상품 리스트를 보여주는 테이블 영역장바구니의 상품 목록을 렌더링하기 위해 CartStore에서 cart 스테이트를 조회하며 장바구니 상품 삭제, 수량 변경을 위해 removeCartItem, changeCartItemCount 액션을 가져옴. 그리고 어떤