Medium

7주차 과제 체크포인트

기본과제

Medium

• 총 11개의 파일, 115개의 단위 테스트를 무사히 작성하고 통과시킨다.

질문

Q. medium.useEventOperations.spec.tsx > 아래 toastFn과 mock과 이 fn은 무엇을 해줄까요?

notistack 라이브러리의 useSnackbar 훅을 모킹하여 테스트 환경에서 스낵바 호출 여부와 메시지를 검증할 수 있게 해줍니다. 테스트 환경에서는 실제 UI 스낵바를 띄우지 못하기 때문에 enqueueSnackbarFn이 호출되었는지, 어떤 메시지가 전달되었는지 확인하는 방법을 사용합니다.

const enqueueSnackbarFn = vi.fn();

vi.mock('notistack', async () => {
  const actual = await vi.importActual('notistack');

  return {
    ...actual,
    useSnackbar: () => ({ enqueueSnackbar: enqueueSnackbarFn }),
  };
});

Q. medium.integration.spec.tsx > 여기서 ChakraProvider로 묶어주는 동작은 의미있을까요? 있다면 어떤 의미일까요?

테스트 환경에서 실제 운영 환경과 동일한 Context 제공자들을 설정하여 컴포넌트가 정상적으로 동작할 수 있게 만듭니다. SnackbarProvider는 notistack에서 useSnackbar 훅을 사용할 수 있게 만드는 컨텍스트 프로바이더이고, ThemeProvider는 MUI 컴포넌트들이 theme를 받아서 올바르게 렌더될 수 있게 만드는 프로바이더입니다.

import CssBaseline from '@mui/material/CssBaseline';
import { ThemeProvider, createTheme } from '@mui/material/styles';
import { render } from '@testing-library/react';
import { SnackbarProvider } from 'notistack';
import type { ReactElement } from 'react';

import { App } from '../App';

//...

const setup = (element: ReactElement) => {
  const theme = createTheme();
  const user = userEvent.setup();

  return {
    ...render(
      <ThemeProvider theme={theme}>
        <CssBaseline />
        <SnackbarProvider>{element}</SnackbarProvider>
      </ThemeProvider>
    ),
    user,
  };
};

Q. handlersUtils > 아래 여러가지 use 함수는 어떤 역할을 할까요? 어떻게 사용될 수 있을까요?

MSW의 server.use()를 통해 특정 테스트에서만 사용할 임시 핸들러를 등록합니다. 각 테스트마다 독립적인 환경을 만들어 병렬 실행 시에도 안정적인 테스트를 가능하게 하며, 특정 엔드포인트에 대해 성공 혹은 실패, 그리고 리턴값까지 정해서 보내줄 수 있습니다.

import { http, HttpResponse } from 'msw';

import { server } from '../setupTests';
import type { Event } from '../types';

export const setupMockHandlerCreation = (initEvents = [] as Event[]) => {
  const mockEvents: Event[] = [...initEvents];

  server.use(
    http.get('/api/events', () => {
      return HttpResponse.json({ events: mockEvents });
    }),
    http.post('/api/events', async ({ request }) => {
      const newEvent = (await request.json()) as Event;
      newEvent.id = String(mockEvents.length + 1); // 간단한 ID 생성
      mockEvents.push(newEvent);
      return HttpResponse.json(newEvent, { status: 201 });
    })
  );
};

Q. setupTests.ts > 왜 이 시간을 설정해주는 걸까요?

beforeEach(() => {
  expect.hasAssertions(); // ? Med: 이걸 왜 써야하는지 물어보자
  vi.setSystemTime(new Date('2025-10-01')); // ? Med: 이걸 왜 써야하는지 물어보자
  resetEvents();
});

모든 테스트가 동일한 기준 날짜(2025-10-01)를 사용하도록 보장하여 시간 의존적인 로직을 안정적으로 테스트할 수 있게 합니다. 타임존의 차이나 실제 실행시점이 달라서 발생하는 테스트케이스를 제거하기 위한 설정입니다.

관련 내용 정리본

• https://github.com/chan9yu/front_6th_chapter3-1/issues/1
• https://github.com/chan9yu/front_6th_chapter3-1/issues/2

심화 과제

• App 컴포넌트 적절한 단위의 컴포넌트, 훅, 유틸 함수로 분리했는가?
• 해당 모듈들에 대한 적절한 테스트를 5개 이상 작성했는가?

과제 셀프회고

이번 과제를 통해 테스트 코드 작성의 전체적인 흐름을 경험할 수 있었습니다. 그동안 테스트 코드를 실제로 써본 적이 없어서 Medium 난이도를 선택했는데, 결과적으로 목표였던 모든 테스트 케이스를 작성하게 되었습니다. 테스트 작성뿐만 아니라 컴포넌트 분리 작업까지 함께 하면서 재미있는 과제가 되었던거 같아요

기술적 성장

이번 과제를 통해 React Testing Library의 핵심 개념인 getBy, queryBy, findBy의 차이점과 활용법을 배울 수 있었습니다. MSW를 통한 API 모킹과 네트워크 요청 가로채기 하는 방법도 써볼 수 있었고, 컴포넌트 단위 테스트와 통합 테스트의 차이점을 실제로 구현하면서 어느정도 감을 잡을 수 있었습니다.

구현하면서 어려웠던 건 MUI 컴포넌트 테스트할 때 올바른 selector를 고르는 것이였는데, aria-label과 role 속성을 잘 활용해서 접근성을 고려한 테스트 작성법을 사용해봤습니다.

코드 품질

코드 품질을 높이기 위해서 테스트를 먼저 짜고 그 다음에 컴포넌트를 쪼개는 방식으로 진행했습니다. 테스트가 깨지지 않는 선에서 조금씩 컴포넌트를 분리해나갔습니다.

물론 아직 부족한 부분도 많은데요.. 컴포넌트를 나누다 보니 props를 여러 단계로 내려주는 일이 많아졌고, 테스트 케이스 중에는 비슷한 로직이 중복되는 것들도 있어서 정리가 필요한 거 같습니다.

학습 효과 분석

이번 과제에서 가장 크게 얻어간건 테스트 코드 작성의 전체적인 흐름을 이해한 것입니다. 그냥 기능이 잘 돌아가는지만 보던 것에서 벗어나서, 실제로 사용자가 쓰는 관점에서 컴포넌트가 제대로 동작하는지 확인하는 방법을 배웠고 앞으로 개발할 때 기회가 된다면 테스트 코드를 통해 코드 품질도 높일 수 있을 것 같습니다

아직 더 공부해야 할 부분들도 많은 거 같습니다 복잡한 상태 관리가 있는 컴포넌트를 어떻게 테스트할지, E2E 테스트와 단위 테스트를 어떤 비율로 써야 할지, 테스트 커버리지와 실제 품질 사이의 적절한 선을 어떻게 찾을지 같은 것들.... 역시 실제로 테스트 코드를 많이 짜봐야 알 거 같아요

과제 피드백

과제에서 좋았던 부분은 테스트 처음 하는 사람을 위해 여러 난이도가 있다는 점입니다. 저는 Medium 난이도를 통해 유닛 테스트부터 시작해서 통합 테스트까지 자연스럽게 배울 수 있었고, 실제 사용자가 쓰는 시나리오로 만든 통합 테스트가 재미있었습니다. 이런 식으로 단계별로 접근하니까 테스트의 전체적인 흐름을 이해할 수 있었던거 같아요

리뷰 받고 싶은 내용

테스트 케이스의 범위에 대한 고민이 있습니다 "컴포넌트가 렌더링되는가" 같은 기본적인 테스트부터 복잡한 사용자 시나리오까지 다양하게 작성했는데, 어느 정도 선에서 테스트를 작성하는 게 적절한지 궁금합니다. 특히 단순한 렌더링 테스트가 실제로 의미가 있는 건지, 아니면 좀 더 비즈니스 로직에 집중해야 하는 건지 아직 감을 잘못잡았습니다...

테스트 코드의 중복에 대해 궁금한 점도 있습니다! 비슷한 로직을 테스트하는 케이스들이 있는데, 이런 경우 테스트를 합치는 게 좋을지 아니면 각각의 케이스를 명확하게 구분해서 유지하는 게 좋을지 조언을 받아보고 싶습니다!