통합 테스트

단위 테스트보다 넓은 범위로 두 개 이상의 모듈이 상호작용 하여 발생하는 상태를 검증할 수 있다.

단위 테스트에 비해 모킹이 적으며 모듈간 발생하는 에러도 검증할 수 있기 때문에 실제 앱의 비즈니스 로직과 가깝게 기능을 검증할 수 있다.

통합 테스트 작성할 때 중요한 것은 컴포넌트의 상태 및 데이터를 어디서 관리하고 변경할 지 구조적인 설계가 잘 되어야 한다는 것이다.

통합 테스트는 주로 컴포넌트간의 상호작용이나 API 호출 및 상태 변경에 따른 UI 변경 사항을 검증한다.

거대한 통합 테스트는 모킹 코드가 증가하고 일부 컴포넌트만 수정해도 많은 테스트가 깨질 수 있다. 따라서 적절하게 나눠서 통합 테스트를 작성하는 것이 중요하다.

비즈니스 로직을 기준으로 통합 테스트를 작성하면 테스트를 명세 자체로 볼 수 있어 앱을 이해하는데 큰 도움을 줄 수 있고 불필요한 단위 테스트를 줄여 유지 보수 측면에서도 효과적이다.

통합 테스트의 한계

비즈니스 로직을 나누어 컴포넌트의 상호 작용을 검증하는 데는 매우 효율적이지만 비즈니스 로직을 나누어 테스트 하기 위해 모킹에 의존하다 보니 전체 워크 플로우를 검증하기에는 한계가 존재한다.

이런 통합 테스트의 한계는 E2E 테스트로 해결할 수 있다. E2E 테스트는 앱 자체를 구동시켜 모킹에 의존하지 않고 실제 데이터와 API를 사용하여 모든 워크플로우를 검증할 수 있다. 앱을 구동시켜 검증하기 때문에 원하는 시나리오를 거의 실제 상황과 동일하게 검증할 수 있다.

따라서 개발 단계에서는 단위 테스트와 통합 테스트를 통해 비즈니스 로직을 검증하고 어느 정도 앱이 완성되었을 때 전체 워크플로우를 E2E 테스트로 검증하여 통합 테스트의 한계점을 보완하는 방식으로 테스트 전략을 세울 수 있다.

비즈니스 로직을 기준으로 통합 테스트를 나누는 기준

• 가능한 모킹을 하지 않고 최대한 앱의 실제 기능과 유사하게 검증하기
• 비즈니스 로직을 처리하는 상태 관리나 API 로직은 상위 컴포넌트로 응집해 관리
• 변경 가능성을 고려해 여러 도메인 기능이 조합된 비즈니스 로직은 나누어 통합 테스트 작성 ex) 메인 홈페이지 → 사용자 로그인 + 상품 검색 + 상품 리스트 분리