[권오연] 8장: 좋은 리액트 코드 작성을 위한 환경 구축하기

8장/권오연.md

@@ -0,0 +1,103 @@
+## 8.1 ESLint를 활용한 정적 코드 분석
+
+### 8.1.1 ESLint 살펴보기
+
+- ESLint는 어떻게 코드를 분석할까?
+    - 자바스크립트 코드를 문자열로 읽는다.
+    - 자바스크립트 코드를 분석할 수 있는 파서(parser)로 코드를 구조화한다.
+    - 2번에서 구조화한 트리를 AST(Abstract Syntax Tree)라 하며, 이 구조화된 트리를 기준으로 각종 규칙과 대조한다.
+    - 규칙과 대조했을 때 이를 위반한 코드를 알리거나 수정한다.
+    - → 한 줄 밖에 안되는 코드가 JSON으로 이렇게 큰 트리가 되는 걸 보니 husky를 이용한 커밋이 왜 그렇게 오래 걸렸는지 알겠다..
+
+### 8.1.2 eslint-plugin과 eslint-config
+
+- eslint-plugin
+    - lint 규칙들을 모아놓은 패키지
+- eslint-config
+    - eslint-plugin을 묶어서 완벽하게 한 세트로 제공하는 패키지
+    - 일부 IT 기업들에서 공개한 잘 만들어진 eslint-config
+        - eslint-config-airbnb
+        - @titicaca/triple-config-kit
+        - eslint-config-next
+
+### 8.1.3 나만의 ESLint 규칙 만들기
+
+- 이미 존재하는 규칙을 커스터마이징해서 적용하기: import React를 제거하기 위한 ESLint 규칙 만들기
+- 완전히 새로운 규칙 만들기: new Date를 금지시키는 규칙
+
+### 8.1.4 주의할 점
+
+- Prettier와의 충돌
+    - 코드 포매팅 도구인 Prettier와 비슷한 기능도 ESLint가 제공하기 때문에 충돌이 발생할 수 있다.
+    - ESLint 에서 코드 포매팅에 관련된 규칙을 끄는 것으로 해결이 가능하다.
+- 규칙에 대한 예외 처리, 그리고 react-hooks/no-exhaustive-deps
+    - useEffect와 useMemo에서 의존성 배열이 필요할 때, 위 규칙을 끄는 경우가 있다.
+    - 하지만 위험한 발상이며, 잠재적인 버그를 야기할 수 있다.
+    - 의존성 배열이 없어도 되는 경우라면 컴포넌트의 상태와 별개로 동작하기 때문에 선언 위치를 다시 고민해 보자.
+    - 의존성 배열이 너무 긴 경우라면 useEffect 내부 함수 내용이 너무 길다는 것과 동일하다. 함수를 쪼개자.
+    - 마운트 시점에 한번만 실행하고 싶은 경우라면 `[]`로 의존성 배열을 작성하곤 한다. 이 방법은 클래스형 접근방법이고 함수형에는 맞지 않을 수 있다.
+- ESLint 버전 충돌
+
+## 8.2 리액트 팀이 권장하는 리액트 테스트 라이브러리
+
+- 프론트엔드 테스트는 일반적인 사용자와 동일하거나 유사한 환경에서 수행
+    - 사용자가 프로그램에서 수행하는 주요 비즈니스 로직이나 모든 경우의 수를 고려
+
+### 8.2.1 React Testing Library란?
+
+- DOM Testing Library를 기반으로 만들어진 테스팅 라이브러리
+
+### 8.2.2 자바스크립트 테스트의 기초
+
+- 테스트할 함수나 모듈을 선정한다.
+- 함수나 모듈이 반환하길 기대하는 값을 적는다.
+- 함수나 모듈의 실제 반환 값을 적는다.
+- 3번의 기대에 따라 2번의 결과가 일치하는지 확인한다.
+- 기대하는 결과를 반환한다면 테스트는 성공이며, 만약 기대와 다른 결과를 반환하면 에러를 던진다.
+- 테스팅 프레임워크
+    - Jest
+    - Mocha
+    - Karma
+    - Jasmine
+- assertion 라이브러리
+    - should.js
+    - expect.js
+    - chai
+
+### 8.2.3 리액트 컴포넌트 테스트 코드 작성하기
+
+- 정적 컴포넌트인 경우 (무상태 컴포넌트)
+    - `beforeEach` : 각 테스트를 수행하기 전에 실행하는 함수
+    - `describe` : 비슷한 속성을 가진 테스트를 하나의 그룹으로 묶는 역할. 필수는 아니지만 가독성을 위한 코드
+    - `it` : test의 축약어
+    - `testId` : get 등의 선택자로 선택하기 어렵거나 곤란한 요소를 선택하기 위해 사용
+- 동적 컴포넌트인 경우 (useState를 이용해 상태값을 관리하는 컴포넌트)
+    - `setup` 함수: 내부에서 컴포넌트를 렌더링하고 테스트에 필요한 button과 input을 반환
+    - `userEvent.type` : 사용자가 타이핑하는 것을 흉내내는 메서드
+        - `fireEvent` 보다 조금 더 자세한 테스트가 가능
+    - `jest.spyOn` : 어떠한 특정 메서드를 오염시키지 않고 실행이 됐는지, 또 어떤 인수로 실행됐는지 등 실행과 관련된 정보만 얻고 싶을 때 사용
+    - `mockImplementation` : 해당 메서드에 대한 모킹 구현.
+- 비동기 이벤트가 발생하는 컴포넌트
+    - msw의 rest 활용
+
+### 8.2.4 사용자 정의 훅 테스트하기
+
+- react-hooks-testing-library
+- `renderHook`
+
+### 8.2.5 테스트를 작성하기에 앞서 고려해야 할 점
+
+- 프론트엔드 테스트는 커버리지가 100%라고 하더라도 유저의 입력이 자유롭기 때문에 모든 상황을 커버하기 어렵다.
+- 애플리케이션에서 가장 취약하거나 중요한 부분을 파악하는 것이 가장 중요
+
+### 8.2.6 그 밖에 해볼 만한 여러가지 테스트
+
+- 유닛 테스트: react-testing-library
+- 통합 테스트: react-testing-library
+- 엔드 투 엔드 테스트: cypress
+    - cypress로 티켓팅, 리셀봇, 수강신청봇 등 응용 가능 https://www.inflearn.com/course/%EB%A6%AC%EC%85%80%EB%B4%87-%EC%9B%90%EB%A6%AC%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-cypress
+
+
+### 8.2.7 정리
+
+- 결국은 애플리케이션이 비즈니스 요구사항을 충족하는지 확인하는게 목표