Recoil - 함수형 프로그래밍의 원칙
- 같은 인풋이 들어오면 아웃풋이 같아야 (= 순수 함수)
- atom을 일반 유틸리티 함수에서 use~ 메서드로 불러오면
- use~ 커스텀 훅은 컴포넌트 안에서만 불러와야 한다는 규칙 위반
- 무엇보다 순수 함수의 원칙에 어긋남 (atom 값이 달라지면 유틸리티 함수의 리턴 값이 달라짐)
테스트 코드
무엇을 테스트할 것인가?
- 프론트엔드는 사용자가 무엇을 쓰는지 테스트하는 것
- 예: 이메일 / 비밀번호 / 버튼
- 스타일 연산 테스트는 의미 없음
- 디바이스마다 컴포넌트의 정확한 크기가 달라지기 때문
- 해당 컴포넌트가 있는지 없는지(렌더링 되었는지) 정도만 보면 됨
- 하지만 UI 테스트는 굳이 할 필요 x
- 사용자의 시나리오 테스트에 집중해야
- 기획자 스토리에 맞게 테스트 코드를 짜게 된다.
- 예: 이메일 / 비번에 인풋이 입력될 때마다 유효한지 안내 문구 출력
- 로그인 화면의 목적: 로그인이 성공했는지 실패했는지 + 이후 화면이 잘 리다이렉트되는지
- 테스트 대상: 사용자가 이 서비스/화면을 쓸 때 어떤 것을 중점적으로 볼지를 고려
- 버튼이 잘 보이는가(X)
- 버튼이 요구 조건에 맞게 활성화되는가(X)
- 로그인 성공 또는 실패 시나리오에 맞게 잘 동작하는가 (O) ⇒ 이것만 테스트 - 너무 초반부터 TDD를 하면 프로젝트 초반에 요구사항 변경에 맞게 유연하게 대응하기 어려움
- 서비스 운영할 때 꼭 필요한 비즈니스 로직만 테스트한다.
- 예: 로그인이 잘 되는지 확인
- '로그인' 버튼 클릭 시의 이벤트 핸들러가 잘 동작하는지 보기 위해
- ⇒ '로그인' 버튼이 잘 그려지는지 확인하는 것 (UI 테스트의 의미는 이 정도)
어디까지 테스트할 것인가?
- 프론트는 유닛 테스트와 통합 테스트의 경계가 애매함
- 프론트에서는 어차피 하나를 테스트하기 위해 여러 가지를 조합해서 확인해야 하기 때문에
어떻게 테스트할 것인가?
- Given - When - Then
- 테스트를 하고 나면 True 또는 False를 리턴해야
- 즉, 결과 값을 기대(expectation)와 비교해서
- 성공했는지 실패했는지 확인해야
유닛 테스트 (Jest)
- describe
- 테스트할 컴포넌트 단위
- 여러 개의 test, it을 포함
- nock, act는 Jest 공식 문서에 없고, expect는 공식 문서에 있음
- 테스트 코드는 하드 코딩해서 넣어주는 게 좋다.
- 변수를 넣으면 ‘가변적’이 되기 때문에
프론트엔드 TDD
- 프론트에서는 완벽한 TDD 불가능
- 기획에서 요구 사항이 변경될 경우 대응이 힘들어짐
- 테스트 자동화
package.json에서“test”의“jest —watchAll”을 test 대신"build"앞쪽에 넣어주면 됨- 형태:
“build”: “jest —watchAll && ...”
=> 빌드 전에 jest를 먼저 돌리게 된다
Jest에서 비동기 테스트
- 비동기 테스트를 위해 nock이라는 것을 사용
라이브 디버깅 에러 고치기
- 버튼 클릭(act)을 하고 나서 비동기(nock)를 실행해야 제대로 돌아간다.
=> jest에서 테스트 코드 순서 중요
데이터 분석가 준비 중입니다 (티스토리에 기록: https://cherylog.tistory.com/)