인프런 커뮤니티 질문&답변

안녕하세요 종민님~!

우선 말씀하신 것처럼 커스텀 훅의 경우 비즈니스 로직 자체에 대한 입력과 결과 특히 상태의 변화에 대해 테스트를 작성하는 것이라 할 수 있습니다. 그리고 컴포넌트 역시 사용자가 이벤트를 발생시켰을 때의 상태 변화를 검증하는 상태 기반 검증이라 할 수 있습니다.

일반 함수나 커스텀 훅과는 다르게 내부적으로 캡슐화되어 사용되는 React의 state가 검증 대상이 아닐 뿐, 이 상태가 DOM에 제대로 반영되는지 DOM의 상태 변화를 검증합니다. 즉, 컴포넌트 통합 테스트 역시 상태 기반의 검증이라 할 수 있습니다. 컴포넌트의 상태가 올바르게 DOM에 반영되는지 검증하고 있기 때문이죠.

(컴포넌트의 상태 검증을 위한 테스트 코드 작성 형태가 이벤트를 통한 행동 기반인 것이지, 테스트 검증 자체는 결국 DOM 상태를 기준으로 하고 있습니다!)

다만, 강의 예제에서 일부 케이스 테스트는 말씀하신 행위 기반의 테스트로 작성되어 있습니다. 바로 리액트 라우터를 통한 네비게이션 검증이 대표적인 예시인대요. JSDOM 기반의 테스트 구동 환경은 실제 브라우저 환경이 아닙니다. 그렇기 때문에 제대로 url이 변경되는지 검증하기 어려우며, 그렇다고 외부 라이브러리인 리액트 라우터의 내부 구현에 따른 상태를 테스트에서 검증하게 되면 배보다 배꼽이 더 커지는 형태가 됩니다.

이렇게 내부 테스트에서 검증하기 힘든 외부 영역(라이브러리 또는 다른 외부 시스템)이 있을때는 spy나 mock을 사용해 행위 기반으로 검증합니다. 예제의 경우 링크 이동에 필요한 navigate함수가 호출되었는지 spy를 통해 행위 기반으로 검증하고 있습니다.

spy나 mock을 사용한 테스트는 대부분 어떤 행위를 했는지 안했는지 검증하기 때문에 실제 상태가 올바르게 변경되었는지 정확성있게 검증하지는 못합니다. 그렇기 때문에 프런트엔드 테스트에서도 특별한 경우가 아니면 spy나 mock을 많이 사용하지는 않습니다.

강의에서는 msw를 사용한 API 응답 데이터를 갈아끼우는 행위도 모킹이라고 표현해서 헷갈리실 수 있는대요. 사실 이 부분도 응답 데이터를 우리가 원하는 데이터로 고정하여 상태를 검증하는 것이기 때문에 일종의 stub이라고 할 수 있습니다.

(테스트더블에 대한 내용은 2부 강의 후반부에 좀 더 자세히 설명하니 참고 부탁드립니다 🙂)

내용이 길었는대요. 정리하자면 아래와 같습니다.

• 컴포넌트의 상태가 올바르게 DOM에 반영되는지 검증하고 있기 때문에 컴포넌트 통합(또는 단위) 테스트 역시 상태 기반의 검증이다. 대부분의 프런트엔드 테스트에서는 특별한 경우가 아니면 DOM 상태를 확인하는 상태 기반으로 검증한다.

• 외부 라이브러리 또는 시스템 내에서 제어할 수 없는 영역의 경우 spy나 mock을 사용하여 행위 기반으로 검증한다.

• msw를 사용한 API 응답 데이터를 갈아끼우는 것도 우리가 원하는 상태를 검증하기 위해 만든 stub이다.

혹시 더 궁금한 사항이 있다면 얼마든지 댓글로 남겨주세요!