minjaeleee 님의 상세페이지 ＞ [6팀 이민재] Chapter 3-1. 프론트엔드 테스트 코드

[6팀 이민재] Chapter 3-1. 프론트엔드 테스트 코드

by minjaeleee2025. 8. 21.

난이도에 맞는 템플릿을 선택해서 작성해주세요!

Medium

7주차 과제 체크포인트

기본과제

Medium

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

질문

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

  • vi.fn()으로 생성된 enqueuesnackbarFn은 토스트 메시지 출력 함수를 모킹한 가짜 함수입니다.

  • vi.mock(’notistack’, async callbackFn())은 React 알림 라이브러리인 ‘notistack’ 라이브를 테스트 환경에서 동작시키기 위해서 모킹하고, useSnackbar 훅을 모킹합니다. 실제 토스트 UI 대신 enqueueSnackbarFn mock(위에서 설명한 모킹 가짜 함수)를 반환하도록 설정합니다.

  • 대표적인 기능은 아래와 같은 알림 기능을 수행합니다.

    • 성공 시: "일정이 추가되었습니다"
    • 수정 시: "일정이 수정되었습니다"
    • 삭제 시: "일정이 삭제되었습니다"
    • 에러 시: "이벤트 로딩 실패", "일정 저장 실패", "일정 삭제 실패" 등

  • 테스트에서 실제 토스트 UI를 띄우지 않고도 올바른 메시지가 호출되는지 검증할 수 있습니다.

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

  • Provider는 실제 운영환경과 동일한 조건에서 테스트할 수 있도록 해줍니다. 만약에 Provider 없이 렌더링하면 MUI 컴포넌트나 토스트가 제대로 동작하지 않아 테스트가 실패할 수 있습니다.
  • Provider의 기능은 아래와 같습니다.
    • ThemeProvider: Material-ui 컴포넌트들이 일관된 테마를 사용할 수 있게 합니다.
    • CssBaseline: 브라우저 간 일관된 CSS 기본값을 제공하고, mui 기본 스타일을 적용합니다.
    • SnackBarProvider: notistack 라이브러리의 토스트 알림 시스템을 활성화합니다. 앱에서 성공/에러 메시지를 표시할 때 필요합니다.

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

각 함수들은 MSW로 특정 시나리오별로 API 응답을 모킹하는 역할을 합니다. (CRUD)

  • 각 함수의 역할들의 예시는 아래와 같습니다.
    1. setupMockHandlerCreation: 일정 생성/조회 기능을 모킹 - GET /api/events: 초기 이벤트 목록 반환 - POST /api/events: 새 이벤트 추가
    2. setupMockHandlerUpdating: 일정 수정 기능을 모킹 - PUT /api/events/:id: 기존 이벤트 수정
    3. setupMockHandlerDeletion: 일정 삭제 기능을 모킹 - DELETE /api/events/:id: 이벤트 삭제 (성공)
    4. setupMockHandlerDeleteError: 삭제 에러 시나리오 - DELETE 요청 시 500 에러 반환

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

  • vi.setSystemTime(new Date('2025-10-01'))를 설정하는 이유는 시간에 의존적인 테스트를 안정적으로 만들기 위함입니다:

    beforeEach(() => {
  expect.hasAssertions();
  vi.setSystemTime(new Date('2025-10-01'));
});

  • 시간 고정이 필요한 이유는 캘린더 앱에서는 현재 날짜와 시간에 따라 동작이 달라집니다. 그렇다는건 현재의 환경에 따라 테스트에 영향을 많이 주고, 독립적인 테스트 환경을 제공하지 못하고, 테스트 안정성이 매우 불안합니다.

  • 따라서, setupTests는 모든 날짜 관련 로직을 예측 가능하게 만들고 테스트가 언제 실행되든 일관성 있는 결과를 보장하는 역할을 합니다.

심화 과제

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

과제 셀프회고

기술적 성장

  • 일단, 테스트에 대한 경험이 거의 없다보니 초기엔 코드 한줄 한줄 문서를 보며 테스트를 실행시키며 해결해가는 과정이 시간이 촉박하기도 하고, 성취감을 느끼기도 했습니다.
  • MSW로 API 호출을 다양한 시나리오별로 모킹해보면서(한 때는…. hard…) MSW에 대한 이해도를 높였습니다. 덕분에 운영 api를 확인하고, 모킹 MSW API를 만들 수 있게 되었습니다. (아마?)
  • Testing 라이브러리를 통해 사용자 중심의 테스트 작성과 접근성을 고려한 쿼리를 선택하는 방법에 대해서 배웠습니다.

학습 효과 분석

  • 사실 테스트 코드가 실용적으로 필요한 것인지에 대한 의문을 항상 가지고 있었습니다. 그런데 가장 큰 필요성을 느꼈을 때가 바로 리팩토링 과제 때 였습니다. 저도 이직한 회사에서 입사 3개월 차 쯤에, 번들 시스템 개선과 노드 및 패키지 파일들 업그레이드를 하는 프로젝트를 할 때가 있었는데 그 때는 참 막막했습니다..

    아직 내부 기능도 다 모르는데 나한테 이걸 맡기면 내가 어떻게 적절하게 테스트를 해야하지? 라는 의문이 있었습니다. 전체 패키지를 업데이트를 하면 사용하고 있는 라이브러리 내부 모듈에서 함수, 문법, props 등이 바뀔 수 있기 때문에 테스트가 필요했습니다. 결국엔 적절한 방법을 생각하지 못 하고 직접 모든 UI/UX를 테스트 해보았는데요. 이때 테스트 코드가 있었다면 훨씬 안정적으로 프로젝트를 수행할 수 있었을 것 같습니다.

  • 이 테스트 코드 과제 덕분에 안정적이고, 독립적으로 테스트 코드를 작성하는 방법에 대해서 많이 고민해본 것 같습니다. 아직 부족한 점이 많지만 그래도 테스트 코드의 필요성과 장점에 대해서 많이 배웠습니다.

리뷰 받고 싶은 내용

테스트 코드를 안정적이면서 실용적으로 작성하는 방법에 대해서 고민이 됩니다.

테스트 코드를 통해서 예측되는, 기대되는 값을 작성을 하게 되는데 작성을 하다보면 나도 모르게 의도되는 값으로 작성을 하게 될 수도 있을 것 같아요. 특히, 이와 같은 과제(캘린더 앱, 시간 제어 기능)처럼 테스트 단위에 적절한 목 데이터를 작성하게 되면 특히나 더 엣지 케이스에 취약할 것 같은데

어떤 식으로 실무에서 테스트 코드를 계획하고 구성하시는지 알고 싶습니다!

과제 피드백

수고했습니다. 이번 과제는 테스트를 하는 다양한 방법들을 접하면서 테스트 코드를 작성한다라는 그 심리적 장벽을 허물고 친숙해지는데 있었습니다. 회고를 보아하니 이번 과제가 좋은 의미가 되어 준것 같네요.

"초기엔 코드 한줄 한줄 문서를 보며 테스트를 실행시키며 해결해가는 과정이 시간이 촉박하기도 하고, 성취감을 느끼기도 했습니다." 맞아요. 처음엔 막막하지만 하나하나 이해해가는 과정에서 성취감이 생기죠. 테스트 코드가 당장 실무로는 와닿지 않고 뭔가 다른 세상의 코드 같아서 막연함이 있지만 막상 해보고 나면 아~ 이런거구나 하는 마음이 들었을거에요.

"가장 큰 필요성을 느꼈을 때가 바로 리팩토링 과제 때 였습니다." 좋은 인사이트네요. 실제로 번들 시스템 개선과 노드 업그레이드 같은 작업을 할 때 테스트 코드가 없으면 정말 막막하죠. 테스트 코드의 필요성을 체감하는건 중요한 경험입니다. 그래야 해볼 수 있는 동력이 생기니까요.

Q) 테스트 코드를 안정적이면서 실용적으로 작성하는 방법에 대해서 고민이 됩니다. 나도 모르게 의도되는 값으로 작성을 하게 될 수도 있을 것 같고, 엣지 케이스에 취약할 것 같은데 어떤 식으로 실무에서 테스트 코드를 계획하고 구성하시는지 알고 싶습니다!

=> 함수나 훅 혹은 컴포넌트의 입장보다는 사용자의 입장이 되어 보는 것이에요. 내가 QA라면 의도적으로 여기에 어떤 나쁜 값을 넣어 볼 수 있을까? 이미 UI나 UX등에서 걸러진다거나 만들 수 없는 값들을 생각하지 마세요. 반대로 이런 값들을 실수로 혹은 악의적으로 넣어 볼 수 있겠는데? 하는 식으로 예측하며 엣지 케이스를 떠올려 봅시다.

=> 그렇지만 엣지 케이스에 취약하더라도 정상동작만 체크해주는 테스트 코드라고 충분히 가치가 있어요. 그러니 일단은 만들어 보는 것에 집중을 합니다. 그러다보면 자연스럽게 분명 잘못된 경우인데 테스트가 통과를 하는 경우도 생겨요. 이럴때 아하! 하면서 보강을 해줘도 늦지는 않습니다. 테스트 코드는 한번에 잘 만드는게 아니라 야금야금 함께 성장하는것이니까요.

이번 과제의 경험이 꼭 실무에서도 이어져서 꼭 하나라도 만들어보면서 그 가치를 지속적으로 확인해보길 바라요. 수고하셨습니다.