통합 테스트 대상 선정하기

단위 테스트는 의존성이 적거나 없는 단순한 컴포넌트를 대상으로 한다.(작은 단일 컴포넌트, 유틸 함수, 리액트 훅)

그러나 통합 테스트는 API, 상태 관리 스토어, 컨텍스트 등 다양한 요소들이 결합된 컴포넌트를 기준으로 자식 컴포넌트들이 제대로 렌더링 되는지 검증한다.

예제속 메인 페이지의 비즈니스 로직들로는 다음과 같은것들이 있다 :

• 네비게이션 영역의 로그인 여부에 따른 동작
• api를 통해 필터의 카테고리 데이터를 올바르게 렌더링
• 필터 항목을 수정했을 때 리스트에 올바르게 반영
• api 응답에 따라 상품 리스트가 적절하게 렌더링
• 등등

비즈니스 로직 :

• 프로그램의 핵심 기능을 구현하는 코드
• 즉 사용자가 원하는 결과를 얻기 위한 계산, 처리, 의사 결정을 수행하는 코드

도메인별 분리

좋은 통합 테스트는 비즈니스 로직을 도메인 단위로 잘 나누어 수행되어야 한다.

메인 페이지의 비즈니스 로직들은 다음과 같이 분류될 수 있다.

• 네비게이션 바 영역
  • 로그인 여부에 따른 UI 렌더링(장바구니)과 상호작용(로그인, 로그아웃)
• 상품 검색 영역
  • 필터 설정에 따른 검색 조건 설정
• 상품 리스트 영역
  • 검색 결과에 따른 상품 리스트 렌더링과 버튼 클릭 상호작용(장바구니 추가, 자세히 보기)
• 하나의 거대한 메인 페이지 테스트가 아니라 3개의 작은 테스트로 구성됨.

메인 페이지가 아닌 장바구니 페이지의 경우 비즈니스 로직을 다음과 같이 분리할 수 있다.

• 상품 리스트 영역 : 상품 리스트 렌더링 및 수량 수정, 삭제 버튼 클릭에 따른 상호작용
• 가격 계산 영역 : 모든 상품의 수량과 가격 계산

변경, 추가 사항이 있을때 용이하다

만약에 상품 검색 영역에서 검색 필터에 새로운 필드를 추가하거나 하는등의 변경사항이 있거나, 상품 리스트에서 보여주는 상품의 정보가 변경되거나, 스크롤 로딩 방식에서 페이징 방식으로 변경하는 등의 각 도메인에서의 변경사항이 있어도 해당 도메인의 테스트 코드만 변경하면 된다.

컴포넌트 설계

좋은 코드는 테스트 하기 좋은 코드라는 말처럼 컴포넌트 구조를 설계할때도 테스트의 관점을 사용하면 좋다. 한 페이지에 많은 컴포넌트들이 있는데 페이지에서 모든 상태를 관리해야 할까? 페이지의 규모가 크고 복잡하면 불가능하다. 따라서 자식 컴포넌트들을 도메인 로직 단위로 묶어야 한다.

다음과 같이 테스트를 설계하면 된다.

1. 메인 페이지를 이루는 모든 요소들을 나열하고, 그 요소들을 도메인 단위로 묶어서 상위 컴포넌트를 만든다.
   • 페이지(page.tsx) -> 상위 컴포넌트(ProductList.tsx)-> 하위 컴포넌트(버튼, 상품정보 등 렌더링 되는 ui 요소)
2. 그리고 그 상위 컴포넌트에서 자식 컴포넌트들의 상태 관리나 api 호출을 응집시킨다.
3. 통합 테스트는 위의 상위 컴포넌트 단위로 수행한다.

비즈니스 로직으로 통합 테스트를 분류할 때의 규칙

• 가능한 적은 모킹을 사용한다.
• 상위 컴포넌트에 비즈니스 로직 처리와 상태 관리, API 호출 코드를 응집한다.
• 변경 가능성을 고려해 여러 도메인 기능이 조합된 비즈니스 로직은 나눠서 검증한다.

가능한 적은 모킹 사용하기

모킹은 테스트를 독립적으로 분리하여 효과적으로 검증할 수 있게 도와준다. 그러나 한편 모킹 코드는 관리,파악하기 어려우며, 모킹에 의존하는 테스트는 실제 상황과 멀어지게 된다.

상위컴포넌트에 로직 응집하기

하위 컴포넌트에서 직접 api를 호출하고 복잡한 상태를 가지면 테스트할 때마다 환경을 맞춰야해 복잡해진다. 로직이 응집된 상위 컴포넌트가 있으면 해당 컴포넌트의 테스트를 통해 전체 로직을 검증할 수 있다.