Unit Test | 4.2. 통합 테스트 대상 선정하기

Kate Jung·2024년 2월 21일

Front-end Test

목록 보기

15/17

그렇기 때문에 거대한 책임으로 구성된 비즈니스 로직을 나누어 컴포넌트 집합을 구성하고 이 컴포넌트 집합을 하나의 통합 테스트 단위로 선정하여 테스트 코드를 작성하게 됨

상품 목록을 보여줌
상품명 or 카테고리 정보를 수정하여 원하는 대로 상품 목록의 검색 결과를 확인 가능. 또한 상단의 네비게이션 바 영역에서는 사용자의 로그인 여부에 따라 장바구니의 수량, 회원 이름과 같은 정보들을 보여줌.

즉 페이지 내의 기능 검증을 위해 여기서 설명한 다양한 시나리오에 대한 모킹이 필요

지나치게 많은 모킹

코드상 관리하기 어려움 파악하기도 어렵습니다.
모킹에 너무 의존을 하다보면 테스트 자체의 신뢰성 하락할 가능성 有

이유 : (실제 상황과 유사하게 모킹 데이터를 만들지만) 모든 상황을 모킹을 통해 시뮬레이션 할 수는 없기 때문에

적절하게 통합 테스트를 나누어 작성하는 것이 좋음.

사용자의 요청 역시 결국 비즈니스 로직으로 구현된 서비스의 정책에 맞게 처리됨.

여러 컴포넌트에 걸쳐 있는 서비스의 핵심적인 비즈니스 로직을 독립적인 기능 관점에서 효율적으로 검증 가능

(도메인을 나누어 분리하지 않고) 하나의 거대한 비즈니스 로직에서 이 모든 로직을 처리한다면 (일부 코드만 변경되어도 여기저기 영향을 미쳐) 코드를 관리하기 어려워짐.

또한 이 경우, 거대한 통합 테스트 코드 역시 계속 변경해야 함.

페이지 내 전체 컴포넌트 간 상호작용을 검증하지는 못하지만 중요한 비즈니스 로직 단위로 나누어 필요한 기능은 모두 검증 가능

또한 각 영역별로 필요한 부분만 모킹하면 되기 때문에 상대적으로 테스트 시 필요한 모킹 코드도 감축 가능
비즈니스 로직을 나눌 때도 이러한 사고를 바탕으로 규칙을 만들면 통합 테스트 범위를 좀 더 명확하게 나눌 수 있음.

네비게이션 바 영역에 로그인, 로그아웃 버튼에서 각각 사용자 정보 스테이트를 일일이 조회하여 사용하기보다는 상위 내비게이션 바 영역에서 사용자 정보 스테이트를 관리하는 것이 여기저기 상태 관리 로직이 산재되지 않아 로직 관리에 용이함.

또한 상태 관리가 응집된 컴포넌트를 대상으로 통합 테스트를 작성한다라는 규칙을 만들어 통합 테스트의 범위를 나누고 관리하기도 좋음.

테스트 기반의 사고를 바탕으로 컴포넌트 집합을 설계하게 된다면 API나 상태 관리에 대한 책임을 적절하게 나누어 컴포넌트 간의 결합도를 줄이는 방향으로 이끌어 줌.

그리고 이는 결과적으로 앱의 견고한 설계로 이어지고 적절한 단위로 과도한 모킹 없이 테스트 코드를 작성하기도 수월해짐.
실제 프로덕션 앱에서는 이보다 훨씬 더 복잡하고 변경이 많을 것이기 때문에 비즈니스 로직을 나누는 테스트 기반의 사고를 연습하는 관점으로 생각해 주시면 좋을 것 같음.