프로젝트를 진행하다 보면 개발 일정이 원하지 않는 방향으로 흘러가는 일이 자주 발생한다.
나 같은 경우 백엔드 개발과 프론트 개발을 동시에 진행한 적이 많다.
프론트단에서는 API 의 응답 값에 따라 UI 를 다르게 보여주거나 어떠한 기능을 실행해야 하는 경우가 많은데, 이 경우 2가지 정도의 방법을 적용한 적이 있다.
- 프론트단에서 mock 데이터를 담당하는 json 파일을 생성해서 사용
- 백엔드단에서 별도의 mock server 생성
1번 방법은 기존 서비스 로직에 추가로 적용되다 보니 해당 방법을 적용할 때나 실제 API 를 적용할 때 모두 추가적인 작업으로 인해 시간 비용이 발생하는 문제가 있었고, 2번 방법은 별도의 mock server 를 생성하는 시간 비용 문제와 mock data 가 적용된 사항에 대한 공유가 어려운 문제점이 있었다.
이 문제점들로 인해 답답함을 느끼고 있던 중, MSW 라는 것을 알게 되었고 이를 도입하게 되었다.
정의
MSW(Mock Service Worker) 는 네트워크 요청을 가로채 개별적으로 설정한 mock data 를 응답받을 수 있는 라이브러리이다.
서비스 워커 (Service Worker)
- 브라우저의 백그라운드에서 실행하는 스크립트
- 자바스크립트와 다른 별도의 스레드에서 동작
- 네트워크 요청을 가로채 제어할 수 있음
사용 후기
사용해 보면서 개인적으로 느꼈던 장단점을 정리해 봤다.
장점
- 백엔드의 API 가 완성되지 않아도 API 관련 코드를 미리 작성하고 그에 맞는 설계를 할 수 있었다.
- 이로 인해 테스트 및 mock 데이터 생성에 대한 시간 비용이 절약되었다.
- mock API 에서 실제 API 로 전환이 매우 빠르고 간편했다.
- 회원 탈퇴나 회원 가입 등의 호출 횟수가 제한적인 API 를 테스트할 때 여러번 테스트가 가능했다. (백엔드 개발자에게 데이터 수정 요청을 하지 않아도 되었다.)
- 응답 값에 따른 UI 테스트를 하는 경우 mock 데이터 수정을 통해 간편하게 테스트를 진행할 수 있었다.
- 모든 API 가 아닌 적용하고 싶은 endpoint 에만 적용할 수 있었다.
단점
- 초기 세팅 및 mock data 를 적용해야 하는 번거로움이 존재했다.
- GET 요청의 경우, 백엔드 API 에서 응답받는 json 구조를 아는 경우에 효과적으로 사용이 가능할 것 같았다.
- 백엔드 API 응답 값의 구조가 변경되면 mock 데이터에도 추가로 변경이 필요한 부분이 있었다.
- 서비스 워커 기반이기 때문에 구버전 브라우저는 지원하지 않았다. (내 경우는 구형 안드로이드 os 의 웹뷰 환경에서 동작하지 않았다.)
적용
공통
- msw 설치
- src/mocks/handlers.ts 생성
GET,POST이외의 메서드는 공식 문서에서 확인할 수 있다.- 개인적으로 handlers 폴더에 endpoint 로 파일을 분리해서 관리하는 것을 선호한다.
- src/mocks/browser.ts 생성
React
- src/index.tsx 에 msw 적용
Next.js
- server, browser mock index 파일 생성
- src/mocks/index.ts 생성
- src/mocks/Provider.jsx 생성
- src/app/layout.jsx 코드 수정
공통 마무리
- mockServiceWorker.js 생성
- 해당 명령어를 통해 public 폴더에 msw 를 실행할 수 있는 worker 파일을 생성한다.
- 개발자 도구를 통해 msw 활성화 메시지가 나오면 적용이 완료된 것이다.
이슈
콜론 path 구분
참고
