utterances-bot commented 9 months ago

Next.js에서 MSW(Mock Service Worker)로 네트워크 Mocking하기 | 올리브영 테크블로그

네트워크 Mocking을 위해 고민했던 삽질기

https://oliveyoung.tech/blog/2024-01-23/msw-frontend/

HaeSim commented 9 months ago

저도 최근에 MSW를 도입해서 그런지 재미있게 봤네요 :) 감사합니다. 저도 삽질을 좀 했었는데요, MSW가 초기화 되기 전, 컴포넌트가 이미 렌더링 되면, 렌더링시 호출되는 API콜을 하는 경우에 MSW가 후킹을 제대로 하지 못하는 현상이 있더라구요. 그래서 개발환경에서는 MSW가 초기화 된 이후에 하위 컴포넌트가 렌더링 되도록 App 컴포넌트를 수정 하였는 데, 비슷한 상황이 있었는지 궁금하네요!

mihyunLee commented 9 months ago

강의에서 MSW 도입하는 과정을 진행해봤는데 실제로 도입할 경우 어떠한 문제점이 발생하는지 재밌고 쉽게 풀어주셔서 이해하는데 도움이 많이 되었습니다 :D 글 중에 MSW 도입 이유에 대한 설명 중 '위에서 설명한 Nock이랑 비슷하지만 노에서만 동작하는 Nock 과는 달리' 부분에서 노드에서만 동작하는 Nock 인데 오타가 발생한 것 같아요!

oy-davidbang commented 9 months ago

저도 최근에 MSW를 도입해서 그런지 재미있게 봤네요 :) 감사합니다. 저도 삽질을 좀 했었는데요, MSW가 초기화 되기 전, 컴포넌트가 이미 렌더링 되면, 렌더링시 호출되는 API콜을 하는 경우에 MSW가 후킹을 제대로 하지 못하는 현상이 있더라구요. 그래서 개발환경에서는 MSW가 초기화 된 이후에 하위 컴포넌트가 렌더링 되도록 App 컴포넌트를 수정 하였는 데, 비슷한 상황이 있었는지 궁금하네요!

@HaeSim 안녕하세요 HaeSim님, 먼저 긴 글 읽어주셔서 너무 감사합니다~! 안타깝게도(?) 말씀하신 MSW가 후킹을 제대로 못하는 경험은 따로 존재하지 않았습니다 🙏

제 생각에는 Axios를 사용하신다면 충분히 발생할 수 있는 이슈일 것 같습니다!! axios timeout 기본 값이 0이고 retry를 하지 않기에 발생할 수 있을것 같습니다~! 올리브영 모바일 프로젝트는 API콜 처리를 tanstack-query로 사용하고 있고 timeout시 retry를 3번이 기본값 이기에 발생하지 않았던걸로 생각이 되어지네요🤔

oy-davidbang commented 9 months ago

강의에서 MSW 도입하는 과정을 진행해봤는데 실제로 도입할 경우 어떠한 문제점이 발생하는지 재밌고 쉽게 풀어주셔서 이해하는데 도움이 많이 되었습니다 :D 글 중에 MSW 도입 이유에 대한 설명 중 '위에서 설명한 Nock이랑 비슷하지만 노에서만 동작하는 Nock 과는 달리' 부분에서 노드에서만 동작하는 Nock 인데 오타가 발생한 것 같아요!

@mihyunLee 긴 글 재밌게 읽어주셔서 너무 감사합니다 mihyunLee님~! 오타 찾아주신 덕분에 글에 퀄리티가 더 좋아졌습니다! 바로 수정하도록 하겠습니다~!👍

YeonghunKO commented 9 months ago

handler의 관심사 구분이 인상깊었어요 좋은글 감사합니다:)

참고로, Heasim님의 첫번째 질문은 아래 글을 통해 답변드릴 수 있을것 같아요!

https://v1.mswjs.io/docs/recipes/deferred-mounting

oy-davidbang commented 8 months ago

@YeonghunKO

긴 글 읽어주셔서 감사합니다~! 다음에도 더 좋은 글로 찾아뵙겠습니다 🥰

loco9939 commented 7 months ago

꽤 긴 글임에도 불구하고 글이 좋아서 끝까지 읽게되었습니다. 문제 정의 -> 해결방법도출 방식으로 논리적인 단계를 거치면서 문제를 해결해나가는 모습이 대단하신 것 같습니다. 👍

그동안 프론트엔드에서 mock API는 사용해본 적이 없고 백엔드와 데이터 타입만 공유받아 FE에서 하드코딩으로 데이터 타입에 맞는 mock 데이터를 생성하여 제대로 불러와지는지 체크하고, 이후 API 완성되었을 때 API를 연결하면서 테스트해봤는데 많이 배워갑니다.

마지막으로 질문 하나 남깁니다.

Q. FE에서 mock 데이터를 하드코딩해서 테스트 해보는 것과 MSW를 사용해서 테스트 하는 것의 가장 큰 차이점 혹은 MSW의 장점이 뭐라고 생각하시나요?

oy-davidbang commented 6 months ago

@loco9939

먼저 긴 글 읽어주셔서 감사합니다.

Q. FE에서 mock 데이터를 하드코딩해서 테스트 해보는 것과 MSW를 사용해서 테스트 하는 것의 가장 큰 차이점 혹은 MSW의 장점이 뭐라고 생각하시나요?

A. 가장 큰 차이점은 네트워크 계층에서 API를 목킹한다는게 가장 큰 차이점이라고 생각합니다. 이 단계에서 얻는 이점은 꽤 큽니다. 전통적인 mock 데이터를 하드코딩을 하는 단계에서는 해당 mock 데이터 변수 모듈을 가져와 사용하게 됩니다. 이렇게 되면, 비즈니스 로직에 mock 데이터 의존이 생기게 됩니다. 하지만 네트워크 계층에서 API를 목킹하게 되면, 비즈니스 로직에 mock 데이터가 의존되지 않아 개발자가 배포할 때 mock 데이터를 제거하지 않아도 됩니다!

또 궁금한 부분이 있으시면 언제든 댓글 주시면 빠른시일내에 확인 후 답변 드리겠습니다! 다음에도 더 좋은 글을 가져오도록 하겠습니다!

loco9939 commented 6 months ago

@oy-davidbang

답변 주셔서 감사합니다. 답변을 듣고 제가 이해한 바에 의하면

mock 데이터를 하드코딩하게 되면 배포시 사용될 소스코드에 mock 불러오게 되므로 의존성이 생기게 되지만,

MSW로 테스트를 작성하게 되면 /src/mock 디렉토리에서 관리하는 handlers와 handlers에서 mock 데이터를 불러오는 fixtures 디렉터리를 .gitignore에 추가하여 배포 시에는 mock 데이터를 제거하지 않아도 되는건가요?

하지만 .gitignore에 등록하게되면 다른 개발자들과 협업 시 내가 작성한 테스트 코드를 공유하지 못하는 문제가 발생할 것 같은데.. 제가 이해한 내용이 맞는지 확인 한번 해주시면 감사하겠습니다 :)

좋은 하루 되세요!

oy-davidbang commented 6 months ago

@loco9939

네 말씀대로 협업을 위해서 .gitignore에 handler나 mock data를 제외하지 않는 방향으로 설계하는게 좋습니다! 따라서 빌드시에는 해당 mock data나 handler는 webpack이나 tsconfig에 제외(exclude)하도록 하고 배포를 진행하여야 합니다!

loco9939 commented 6 months ago

@oy-davidbang

아 빌드시에만 제외해서 배포하라는 말씀이시군요 ㅎㅎ 이제 이해했습니다.

바쁘신 와중에도 답변 주셔서 감사합니다! 😊