Testing 소개
왜 tests를 써야하는가?
- 엄청 큰 코드, 수많은 개발자가 있을 때,
=> 코드에 변화를 줄 때 어떤 버그도 만들고 싶지 않을 것임. - 개별 개발자일 때도 적용,
=> 코드를 수없이 리팩토링할 수 있다.
=> 내가 작성한 tests 코드로 run 돌려볼 수 있음 !
Tests의 타입들
Caveat(주의사항):
엄격한 정의 x, 분류가 애매하고, 모두가 동의하지 않을 수 있음
- Unit Testing
1) 하나의 unit code다.
- 함수이면서,
- React Component 이면서,
- API route이다.
2) mocking dependencies를 사용해서 unit test를 다른 코드에서 분리시킨다. - dependencies는 network calls, 혹은 db 함수들이다.
- 분리는 테스트를 더 쉽게 만든다.
- Integration Testing
1) 같이 일하는 2개 이상의 unit들을 test한다.
- 부모/자식 관계 컴포넌트들 (props를 내려서, 그걸로 결과 만드는)
- db랑 상호작용하는 API
- End-to-End (e2e) testing
1) user flow 확인
- 로그인하는 user flow,
- 티켓을 구입하는 user flow
- 구입한 티켓들의 list를 보는 user flow
2) e2e는 프론트엔드랑 상호작용하기 위해서 브라우저를 사용한다.
- Cypress, Selenium
3) 서버랑 db랑 상호작용 할 때
무엇을 test할 것인가?
- 만약 실패한다면 무엇에 대해서 알고 싶은지 고민해보자.
- testing을 한다면 user experience에 적합한 test를 하는 것이다.
테스트 중복성
반복적이고, 불필요한 테스트를 하게 된다.
낮은 수준의 테스트를 작성해야 하는 여러 이유들이 있다.
- unit tests는 smallest한 테스트고, e2e tests는 broad range하다.
- fewer granular tests를 하면, 실패에 기여한 수많은 것들을 찾아내는데 더 오랜시간이 걸린다.
- more graular tests를 하면, 실패를 한 걸 빠르게 찾을 수 있다.
- 그런데 tests를 작성하면 시간이 더 오래 걸린다
=> 따라서, 어떤 tests를 작성하고 얼마나 많은 tests를 작성할지 잘 생각해야 한다!
test 가이드라인
- 요점을 잃게 만드는 mocking일 때는 unit tests를 하지 말자.
- 함수 자체가 실마리인 경우엔, unit tests 하지 말자 (ex. getStaticProps 사용 때)
- e2e tests가 overkill 될 때는 더 정교하게 tests를 하자.
- 덜 복잡한 tests를 진단하는 것을 돕기 위해 더 많은 정교한 tests를 사용하자.
- e2c tests with cypress를 최소화하자. (오랜 runtime이 걸림)
Snapshot tests에 대한 관점
- 테스트 코드를 실행하여 컴포넌트의 출력물을 캡쳐하고, 이후에 비교해서 변경 사항을 감지하는 테스트 방법이다.
- 결과가 변경된 경우엔 테스트가 실패하고, 변경된 결과를 새로운 스냅샷으로 저장할 것인지 묻는 여부 메시지가 출력된다.
- snapshot은 틀리지 않을 때도 경고하기 때문에 쌤은 권장하지 않는다.
강의 기록 블로그