E2E를 전체 테스트라 한다.
순수한 비즈니스 로직을 다룬 리액트 컴포넌트를 테스트한다.
cra는 jest가 포함되어 있다. Sinon이나 Enzyme을 추가할 수도 있다.
참고 - Enzyme은 뭔가
•
shallow: 간단한 컴포넌트를 메모리 상에 렌더링합니다. 단일 컴포넌트를 테스트할 때 유용합니다.
•
mount: HOC나 자식 컴포넌트까지 전부 렌더링합니다. 다른 컴포넌트와의 관계를 테스트할 때 유용합니다.
•
render: 컴포넌트를 정적인 html로 렌더링합니다. 컴포넌트가 브라우저에 붙었을 때 html로 어떻게 되는지 판단할 때 사용합니다.
그래서 왜 갑자기 Enzyme? 효소? 난 이거 안 씀
@testing-library
왜 React Testing Library인가?
React Testing Library는 React 컴포넌트를 테스트하기 위해 설계된 라이브러리다. 과거에는 React 컴포넌트를 테스트하기 위해 Enzyme을 사용했을 수 있다. React Testing Library가 Enzyme과 다른 점은 테스트를 렌더링 할 때 React 컴포넌트의 인스턴스가 아닌 실제 DOM 노드를 사용한다는 점이다.
이건 사용자가 웹 브라우저에서 애플리케이션을 실행하는 실제 환경과 유사한 환경에서 테스트 케이스가 실행된다는 것을 의미한다. 테스트 환경이 사용자가 애플리케이션을 사용하는 환경과 비슷할수록 테스트를 더욱 신뢰할 수 있다.
필자가 React Testing Library를 선호하는 또 다른 큰 이유는 테스트가 사용자가 앱과 상호작용하는 방식과 유사해야 한다는 기본적인 라이브러리의 철학 때문이다. 사용자는 애플리케이션을 사용할 때 state와 props와 상호작용한다는 사실을 알지 못한다. 함수 컴포넌트에서 훅을 사용하는지, 클래스 컴포넌트와 함께 고차 컴포넌트를 사용하는지 신경 쓰지 않는다. 사용자는 그저 인터페이스(버튼, 입력, 모달 등)를 보고 상호작용할 뿐이다.
그래서 올바른 props나 state가 컴포넌트에서 변경되었는지 테스트하는 대신 React Testing Library는 사용자가 보고 수행하는 작업을 테스트하도록 설계되었다. 따라서 접근 가능한 사용자 인터페이스를 구축하고 HTML을 구성할 때 모범 사례를 준수할 수 있다.
대부분 테스팅 피라미드를 따라가게 된다.
단위 테스트 → 통합 테스트 → 전체 테스트
하지만 리액트 어플리케이션은 함수보다는 컴포넌트를 사용하므로 다른 접근 방식이 있다.
“통합 테스트를 주로 작성하고 단위 테스트는 그리 많이 작성하지 않는” 전략이다.
단위, 통합, 전체 테스트가 뭘까?
일반적으로 단위 테스트는 앱의 일부(컴포넌트 등)를 독립적으로 테스트하는 것이고,
통합 테스트는 서로 다른 부분(컴포넌트 등)이 모여 특정 상황에서 잘 엮여서 작동하는지 확인하는 것이다.
통합 테스트의 예는 특정 컴포넌트의 모든 필수 속성값(props)이 자손 컴포넌트에 제대로 전달되었는지 확인하는 것이다.
전체 테스트는 애플리케이션을 브라우저 환경에서 테스트하는 것이다. 이메일 주소를 넣고 비밀번호를 입력해 백엔드 서버로 Form을 제출하는 회원 가입 과정을 흉내낸다.
•
유닛 테스트: 함수 하나하나와 같이 코드의 작은 부분을 테스트하는 것
•
통합 테스트: 서로 다른 시스템들의 상호작용이 잘 이루어 지는지 테스트하는 것
•
기능 테스트(E2E): 사용자와 어플리케이션의 상호작용이 원활하게 이루어지는지 테스트하는 것
튜토리얼 또 다른 목표는 전반적으로 적용할 수 있는 몇 가지 일반적인 테스트 패턴과 모범 사례를 알려주는 것이다.
매번 작성하는 데 고민하지 않고 효율적으로 테스트하는 데 도움이 될 것이다. 대부분의 테스트는 컴포넌트 전반에 걸쳐 적용할 수 있는 공통 패턴을 따른다. 이 패턴은 TDD를 적용하면 더욱 흥미롭다. 테스트를 먼저 작성하고 컴포넌트를 그 뒤에 작성하게 된다.
•
테스트를 위한 간단한 리액트 어플리케이션 설정
2018년도 글이라 그런지 2020년도 이후 Hooks이 주류된 상황에서의 테스팅을 다룰 것 같진 않다. 그래도 맥락은 비슷할테니 끝까지 따라해본다.
App 클래스 컴포넌트를 만든다. counter를 해주는 컴포넌트다.
