MSW를 활용한 API 모킹과 테스트코드

안녕하세요. 노머스 프론트엔드 팀 김민주입니다.

이번 글에서는 MSW를 도입하고 테스트 코드를 작성하면서 배운 내용을 공유해보려고 합니다.

MSW 도입 배경

MSW를 도입하게 된 계기는 멈춰 있던 프론트엔드 테스트 코드를 다시 작성하면서였습니다.

저희 프로젝트는 사용자 권한에 따라 다양한 UI가 노출되고, 권한별로 다른 API 호출이 발생하는 구조입니다. 그렇기 때문에 예상치 못한 오류가 발생할 가능성이 컸고 테스트 코드는 필수적이었습니다.

기존에 작성된 테스트 코드가 있긴 했지만, 시간이 지나면서 로직이 수정되거나 API 응답이 바뀌면서 skip 처리된 코드도 많았고 새로운 케이스가 추가되면서 수정과 보완이 필요했습니다.

이런 문제를 해결하기 위해, API 호출을 가로채 원하는 응답을 모킹할 수 있는 MSW를 도입하게 되었습니다.

MSW(Mock Service Worker)란?

: MSW(Mock Service Worker)는 서비스 워커(Service Worker) 기술을 활용하여 네트워크 레벨에서 API 요청을 가로채고 모킹(mocking)할 수 있는 라이브러리입니다.

특히, 테스트 환경에서 API 요청을 제어하거나, 로컬 브라우저 환경에서 임의의 API 응답을 설정하는 데 유용합니다.

MSW 공식 문서를 참고하여 프로젝트에 설치하고 필요한 설정 파일들을 세팅했습니다. 이제 MSW를 이용해 컴포넌트 테스트를 작성해 보겠습니다.

테스트 케이스 정의

1. 채널에 연결된 멤버십이 없을 때
2. 내가 가입한 멤버십이 없을 때
3. 내가 가입한 멤버십이 있을 때

• 가입한 멤버십이 하나일 때
• 가입한 멤버십이 여러 개일 때

이 테스트 케이스들은 MembershipCardList 컴포넌트의 동작을 확인하기 위해 필수적이었습니다.

// MembershipCardContainer/index.tsx
const MembershipCardContainer =() => {
    const { memberships } = useGetMembershipUsers();

    if (!memberships) return <EmptyLinkedMembership />;
    if (!memberships.user) return <EmptyJoinedMembership />;

    return <MembershipCardListContainer />;
};

MembershipCardList 컴포넌트는 조건에 따라 세 가지 컴포넌트 중 하나를 반환하고 있습니다. 따라서 API 응답별로 분리하여 테스트하는 것이 중요했습니다.

컴포넌트 테스트

테스트는 다음과 같은 순서로 진행했습니다.

MembershipContainer/index.test.tsx

• API 응답에 따라 조건별로 다른 컴포넌트가 반환되는 구조이기 때문에, 테스트 시 server.use()로 API 모킹을 오버라이드했습니다.
  • 응답이 빈 배열일 때
  • 내가 가입한 멤버십이 없을 때
  • 내가 가입한 멤버십이 있을 때

// MembershipContainer/index.test.tsx
describe('MembershipContainer', () => {
    test('멤버십이 없을 때 "멤버십이 없어요" 문구가 노출된다', async () => {
        server.use(
            http.get(`${MembershipApiBaseUrl}/membershipUsers*`, () =>
                HttpResponse.json({
                    success: true,
                    data: EmptyMemberships
                })
            )
        );
		    ...
	test('해당 멤버십에 팬덤명이 있을때 팬덤명이 노출된다', async () => {
        server.use(
            http.get(`${MembershipApiBaseUrl}/membershipUsers*`, () =>
                HttpResponse.json({
                    success: true,
                    data: { memberships: [EmptyJoinedMembershipsWithFandomName] }
                })
            )
        );
  

MembershipCardListContainer/index.test.tsx

• 해당 컴포넌트는 내가 가입한 멤버십이 있을 때 반환되는 컴포넌트에 props로 데이터를 전달받아 렌더링됩니다. 따라서 동일한 컴포넌트를 렌더링하면서 props 값만 바꾸어 다양한 UI 상태를 테스트했습니다.
  • 만료된 멤버십일 경우 멤버십 기간 만료 텍스트 노출
  • 모집이 종료된 멤버십일 경우 “멤버십 모집 종료” 버튼 노출 확인
  • …

// MembershipCardListContainer/index.test.tsx
describe('MembershipCardListContainer', () => {
    test('만료된 멤버십일 경우 멤버십 기간 만료 텍스트 노출', async () => {
        render(<MembershipCardListContainer memberships={ExpiredSingleMembership} />);
        ...
    test('모집이 종료된 멤버십일 경우 "멤버십 모집 종료" 버튼 노출', async () => {
        render(<MembershipCardListContainer memberships={SingleMembershipRecruitEndAt} />);
        ...

이렇게 MSW를 활용해 테스트 코드를 작성해봤습니다.

MSW를 사용하니 API 요청을 네트워크 레벨에서 가로챌 수 있어 실제 API 호출과 분리된 환경에서 테스트코드를 작성 할 수 있었습니다.

또한 server.use() 로 API 응답을 오버라이드해 다양한 케이스를 테스트할 수 있었고 브라우저 환경에서도 모킹된 API 요청과 response를 확인할 수 있었습니다.

이런 부분은 나중에 API가 준비되지 않은 상황에서 작업이 필요할때 케이스별 UI를 확인해보거나 테스트코드를 작성할때 큰 장점이 될 것 같습니다.

MSW 활용 테스트 코드 작성 시 고려 사항 및 개선 방법

이 외에도 MSW를 처음 사용하면서 겪은 어려움과 참고하면 좋을 내용과 더불어 테스트 코드를 짜보면서 느꼈던 내용을 공유해보려고 합니다.

1. 필요한 mockData에 모든 케이스를 하나씩 정의하기보단 먼저 정의해둔 데이터를 활용해서 재사용 ↑

export const SingleMembershipWithFandomName = [
    {
        ...ExpiredSingleMembership[0],
        user: undefined,
        fandomName: '노머스'
    }
];

2. test 파일에서 조건문을 쓰기보다 각 조건에 맞는 mockData 준비

❌
if(membership.name) {
    const name = await screen.findByText(membership.name);
    expect(name).toBeInTheDocument();
}

⭕️
export const SingleMembershipWithName = [
    {
        ...ExpiredSingleMembership[0],
        user: undefined,
        name: '노머스'
    }
];

test('이름이 있을경우 이름 노출 확인', async () => {
    render(<MembershipCardListContainer memberships={SingleMembershipWithName} />);

    const name = await screen.findByText(SingleMembershipWithName[0].Name);
    expect(name).toBeInTheDocument();
});

3. mockData는 상수이므로 Pascalcase 사용(컨벤션에 맞게)
4. 테스트하고자 하는 컴포넌트를 직접 render 해서 테스트 진행

❌
render(
    <>
        <MembershipCardEmpty />
        <MembershipJoinButton />
        <MembershipPromotion />
    </>
);

⭕️
render(<EmptyLinkedMembership />);

: 컴포넌트 자체를 테스트하는 것은 컴포넌트의 구현 방식이 바뀌어도 테스트가 동일하게 작동하도록 보장해 줍니다.

5. mockServiceWorker.js파일은 propduction에 빌드시 제외 필요(https://github.com/mswjs/msw/issues/291)
6. MSW가 2.0으로 업데이트 됐으니 해당 내용 확인하기(https://mswjs.io/blog/introducing-msw-2.0/)

아래는 MSW를 사용하면서 마주한 에러와 해결 방법입니다.

에러 처리

• ReferenceError: BroadcastChannel is not defined
  • 원인 : BroadcastChannel API가 Node.js 환경에서는 기본적으로 제공되지 않고 해당 속성은 Node.js 18 버전부터 있습니다.
  • 해결 : git flow push yaml파일에 세팅된 node version을 16에서 18로 올려서 해결할 수 있었습니다. (참고한 링크를 보면 jset+jsdom 환경일때 jest-fixed-jsdom 로도 해결 가능해 보입니다)
• server.use()로 api 모킹 수정이 되지 않을 때
  • 원인 : react-query로 api를 호출하고 있는데 이전 데이터가 캐시에 남아있어 발생했던 문제
  • 해결 : setupTest파일에 React Query cache를 reset하는 코드 추가해서 해결할 수 있었습니다.

beforeEach(() => {
    queryCache.clear();
});

or

afterEach(() => {
    server.resetHandlers();
    queryClient.clear();
});

논의 사항

• MSW 폴더 구조 : MSW를 검색해보면 폴더 구조를 API주소를 기반으로 구성하는 곳도 있었고, handler와 api를 각각 분리해서 관리하는 곳도 있었습니다. 하지만 이는 모두 mocks파일 내부에 있었고 저희 프로젝트와는 방향이 다르다고 생각했습니다.
  • test파일과 mockData파일은 해당 컴포넌트와 동일한 레벨에 위치
  • mocks폴더 안에는 node setting파일과 browser setting파일만 위치

저희는 이렇게 구조를 설정해 봤습니다. 공식 문서에는 src/mocks/handler.js와 src/mocks/node.js만 적혀있기 때문에 개인이나 회사에 맞는 구조로 만들어가시면 될 것 같습니다.

마치며

이번 작업을 통해 MSW를 도입해 처음으로 테스트 코드를 짜볼 수 있었습니다. 이번에는 MSW를 충분히 활용해보지 못했지만 앞으로 작성하는 테스트 코드에서는 MSW를 더 많이 활용해볼 수 있으면 좋겠습니다.

MSW를 활용한 테스트에 관심이 있으신 분들에게 이 글이 도움이 되길 바라며 글 마치겠습니다.

감사합니다:)

---

[참고 블로그]

• https://fe-developers.kakaoent.com/2022/220825-msw-integration-testing/
• https://oliveyoung.tech/2024-01-23/msw-frontend/