React Test Library 는 사용자가 실제 사용하는 방식으로 테스트 한다
내부 구현은 테스팅하지 않고
소프트웨어가 제대로 작동하는지 확인하는 것
테스트할 요소를 접근성 표시로 찾는다
시뮬레이션 DOM 을 제공하여 테스트를 한다
테스트 러너가 있어야 사용할 수 있다
jest 는 테스트 러너로써 테스트할 요소를 찾고 실행하여 assertions 을 생성, 결과를 반환한다
시뮬레이션 돔과 함께 상호작용을 위한 유틸도 제공한다
시뮬레이션 돔이 있기 때문에 브라우저 없이 사용 가능하다
jest 의 단언
expect(element).toBeIntheDocument()
테스트 통과 여부를 결정하는 것으로
expect() 메서드로 시작한다
expect() 메서드는 관찰할 대상을 인자로 받고
toBeIntheDocument() 같은 matcher 를 사용한다
단언은 작성한대로 동작할 것이라고 확정하고 실행하여
맞으면 통과, 아니면 에러를 발생시켜 테스트에 실패한다
DOM 과 관련된 matcher 를 제공한다
https://github.com/testing-library/jest-dom
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles
jest 의 대부분은 vitest 로 대체될 수 있다
vitest 가 jest 를 기반으로 만들어졌기 때문에
같은 문법을 사용한다
전역 test() 메서드가 있고 2가지 인자를 받는다
1. 테스트에 대한 설명을 담은 문자열
2. 테스트 함수
테스트 주도 개발
테스트 코드를 먼저 작성하고
테스트에 통과하는 코드를 작성하는 것
주로 red-green 테스팅을 한다
테스트를 기반으로 코드를 작성 후
작성된 코드가 테스트에 통과하는지 검증한다
React Testing Library 는 기능 테스트를 하는 것이다
기능 테스트와 유닛 테스트는 상호 배타적인 것이 아니다
기능 테스트로만 테스트 하고 넘어가기에는 복잡한 함수의 경우 유닛 테스트를 진행한다
또한 기능 테스트의 경우 광범위한 기능에 대해 다루기 때문에 실패 원인을 확인하고 싶을 때 사용하면 좋다
유닛 테스트는 테스트를 최대한 격리시키기 때문에 의존성을 작성해야 한다
의존하는 다른 함수 등이 있으면 실제 버전 대신 테스트 버전을 사용한다
때문에 문제가 발생하는 유닛에 대해 명확히 파악할 수 있다
유닛 테스트 내에서 내부 테스트 또한 진행할 수 있다
내부 테스트가 필요한 이유는 유닛 내에서만 테스트 진행 시 때로 상태의 차이점에 대해서만 테스트하게 되기 때문이다
사용자가 소프트웨어와 상호작용 하는 방식과는 거리가 있다
때문에 실제 사용과 무관하게 테스트가 성공할 수 있다
또한 코드 리팩토링으로 인해 내부 로직이 변경되었을 경우에도 실패할 수 있다
특정 동작이나 유저 플로우와 연관된 모든 단위를 포함한다
사용자가 소프트웨어와 상호작용하는 방식과 밀접하다
테스트가 견고하다고 표현하는데 표현하는 동작이 같다면 내부 로직이 변경되어도 테스트가 유지된다
테스트 실패 시 정확한 원인 파악이 어려울 수 있다
RTL 은 기능 테스트의 장점이 단점을 가릴만큼 크다고 생각한다
같은 기능을 한다면 리팩토링이 쉬운 방법이 더 괜찮다고 생각한 것 같다
그렇다고 유닛 테스트의 역할을 무시할 수는 없다
복잡하고 DOM 을 포함하지 않는 개별 함수를 위해 필요하다
테스팅 라이브러리는 접근성 핸들로 요소를 찾을 것을 제안한다
테스트에서 스크린 리더처럼 요소를 찾을 수 없다면 앱이 스크린 리더에 친화적이지 않은 것으로 좋지 않다
fireEvent 로 인터랙션을 테스트
jest-dom 을 다루는 단언들
describe 로 그룹화
단위 테스트