pile·
프론트엔드·카카오 엔터테인먼트 FE카카오 엔터테인먼트 FE·

MSW 모킹 코드 재사용하기 feat. Storybook, Jest

MSW(Mock Service Worker)로 작성한 API 모킹 코드를 Storybook 스토리에 한 번만 정의하고, Jest 테스트에서 중복 없이 재사용하는 패턴을 소개한다. 모킹 코드 중복과 유지보수 비용을 줄이려는 프론트엔드 팀에 실질적인 아이디어를 제공한다.

핵심 포인트 - 문제: Storybook에서 MSW 모킹 정의, Jest에서 동일한 모킹을 server.use()로 한 번 더 작성 → 같은 핸들러가 두 군데 존재 - MSW란: Service Worker 기반 API 모킹 도구. 브라우저와 Node.js 모두 지원해 Storybook과 Jest에서 동일하게 활용 가능 - 핵심 도구: msw-storybook-addon(Storybook MSW 연동), @storybook/testing-react(스토리를 Jest에서 재사용) - 해결 패턴: 스토리의 parameters.msw.handlers에 모킹 핸들러 정의 → composeStories()로 스토리를 Jest에 가져오면 MSW 핸들러도 함께 로드 - 요구 조건: 모킹을 한 곳에서만 정의, Storybook/Jest 테스트 간 모킹이 서로 영향을 주지 않을 것 - 결과: Jest 테스트 코드에서 server.use() 호출 없이 스토리에 이미 정의된 핸들러 자동 적용

상세 정리 - Storybook MSW 설정: npm i -D msw-storybook-addon → .storybook/preview.js에 initialize() + mswDecorator 전역 적용 - 스토리에 핸들러 추가: story.parameters = { msw: { handlers: [rest.get("/api/...", (req,res,ctx) => res(ctx.json(...)))] } } - @storybook/testing-react의 composeStories(): 스토리의 args, decorators, parameters를 모두 포함한 컴포넌트로 변환 - composeStories로 변환된 컴포넌트는 msw-storybook-addon 데코레이터도 포함해 handlers가 자동으로 Jest 환경에서도 적용 - 별도 handler.js 모듈로 분리하는 방식: server.use(handler) 한 줄 필요하지만 스토리 import 방식보다 MSW 핸들러 격리가 명시적 - 스토리 import 방식의 장점: 테스트 코드에서 MSW 설정 관련 보일러플레이트 제거, 스토리와 테스트의 모킹 상태 일치 보장 - msw-storybook-addon은 각 스토리 실행 전후 핸들러를 자동 reset하므로 테스트 격리 요건 충족 - 카카오엔터 멜론 프론트엔드 팀의 실제 적용 사례: SampleAlbumSongList 컴포넌트 예제 사용

왜 읽나: MSW 모킹 코드를 Storybook과 Jest 양쪽에서 중복 없이 관리하는 구체적인 코드 예제와 도구 조합을 통해 테스트 유지보수 비용을 줄이는 패턴을 바로 적용할 수 있다.

카카오 엔터테인먼트 FE
카카오 엔터테인먼트 FE 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 프론트엔드·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    항공 프론트엔드 구축기 (7/10): 창구를 하나만 두었습니다

    여기어때 항공 서비스 프론트엔드가 웹과 앱 웹뷰 두 환경에서 동일한 함수 호출로 동작하는 앱 브릿지 추상화 레이어를 설계한 과정을 다룬다. iOS·안드로이드 규약 차이와 "웹에 존재하지 않는 브릿지를 어떻게 호출하나"라는 문제를 단일 추상화 층으로 해결한 구현 사례다.

    요약 이어보기
    #react#typescript#webview+2