FE ChapterADR 4: 서버데이터 Mocking 시 Apollo MockedProvider 사용
GraphQL을 사용하는 컴포넌트의 단위 테스트를 작성하는 과정에서, 서버와의 네트워크 통신 없이 쿼리 응답을 제어할 수 있는 mocking 전략이 필요
Date: 2025-08-05
Status
Accepted
Context
GraphQL을 사용하는 컴포넌트의 단위 테스트를 작성하는 과정에서, 서버와의 네트워크 통신 없이 쿼리 응답을 제어할 수 있는 mocking 전략이 필요 또한 실제 API 서버와 통신하는 테스트는 네트워크 지연이나 외부 서비스의 일시적 실패로 인해 테스트가 실패할수도 있어서, 항시 테스트의 신뢰성을 확보하고자 mocking 도입이 요구됨
도입배경
- 서버쪽 개발이 늦어질 경우 FE 개발이 밀림
- Apollo Client를 사용하는 컴포넌트 테스트에서 쿼리 응답을 mocking하여 UI 상태 변화만 검증하고자 함
- Storybook에서 GraphQL 기반 UI 컴포넌트를 독립적으로 렌더링하거나, Vitest 기반의 단위 테스트를 수행할 때, 실제 Apollo 클라이언트를 완전히 구성하지 않고도 쿼리 응답을 간편하게 mocking할 수 있는 도구가 필요
- Apollo 공식 지원 도구로 유지 관리가 잘 되고 있으며, @apollo/client/testing 패키지에 포함됨 (Apollo Cache 또는 loading/error 상태를 테스트할 때 유용하게 사용 가능)
- 프로젝트 내에서 GraphQL 쿼리가 복잡해지는 만큼 mocking을 체계화하여 테스트의 신뢰성을 확보하고자 함
Decision
Apollo Client에서 제공하는 MockedProvider를 사용하여 GraphQL 쿼리 및 mutation의 응답을 mocking하기로 결정.
Consequences
긍정적인 결과
테스트 안정성 확보
실제 네트워크 호출 없이도 GraphQL 쿼리 결과를 제어할 수 있어, 테스트가 외부 환경에 영향을 받지 않고 일관성 있게 실행
시나리오 기반 테스트 용이성
성공/실패/로딩 등 다양한 상태를 코드로 명시적으로 정의할 수 있어, 복잡한 UI 로직의 테스트 커버리지가 향상
Apollo 생태계와의 높은 호환성
Apollo Client에서 공식적으로 제공하는 도구임
테스트 코드의 가독성 및 재사용성 증가
mocks 배열을 통해 쿼리와 응답을 작성해서 테스트 코드가 명시적이고 유지보수가 가능
부정적인 트레이드오프
쿼리/변수 변경 시 mock 업데이트 필요
GraphQL 쿼리 또는 변수 스키마가 변경되면 해당 mock 객체도 수정해야 하므로, 유지보수 시 동기화가 요구됨
시스템 및 팀/프로젝트에 대한 영향
테스트 작성의 표준화 가능
MockedProvider를 중심으로 GraphQL 테스트 패턴이 정립되면, 팀적으로 일관된 테스트 스타일을 유지할 수 있음
온보딩 비용의 감소
공식 문서와 예제가 풍부함, 새로운 팀원이 빠르게 테스트 코드를 이해하고 작성가능
msw 도 있는데, ApolloMockedProvider 를 선택한이유?
Apollo MockedProvider 선택 시기:
- Apollo Cache 상태나 loading/error 상태를 세밀하게 테스트해야 할 때
- Graphql Subscription 테스트가 필요할 때
- Graphql Fragment 단위로 테스트가 필요할 때
MSW 선택 시기:
- E2E 테스트나 브라우저 환경 테스트가 필요할 때
- 실제 HTTP 요청/응답을 시뮬레이션해야 할 때
현재 프로젝트의 GraphQL 컴포넌트 단위 테스트 목적에는 Apollo MockedProvider가 더 적합하다고 판단됨. E2E 테스트나 실제 요청/응답 시뮬레이션 테스트가 필요하다면 MSW 도 사용할 수 있음.