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

---

Medium

7주차 과제 체크포인트

기본과제

Medium

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

질문

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

const enqueueSnackbarFn = vi.fn();

vi.mock('notistack', async () => {
  const actual = await vi.importActual('notistack');
  return {
    ...actual,
    useSnackbar: () => ({
      enqueueSnackbar: enqueueSnackbarFn,
    }),
  };
});

React Notistack - https://notistack.com/ notistack이라는 React 알림 라이브러리를 테스트 환경에서 가상으로 동작시키기 위한 모킹 코드입니다. vi.fn()으로 생성된 enqueueSnackbarFn은 실제 알림을 화면에 띄우지 않으면서도 함수 호출 여부, 호출 횟수, 전달된 메시지 등을 추적할 수 있는 함수입니다. vi.mock을 통해 notistack 라이브러리의 useSnackbar 훅만 가짜 함수로 교체하고, 나머지 기능들은 원본을 그대로 유지합니다. 이후 테스트 진행시 enqueueSnackbarFn를 사용하면 테스트 실행 중 실제 팝업이 뜨지 않아 테스트 진행에 방해받지 않으면서도, expect를 사용해 알림 기능이 올바르게 호출되었는지 확인 가능합니다.

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

Provider 래핑은 실제 애플리케이션 환경과 동일한 컨텍스트를 테스트에서 제공하기 위해 필요합니다.

• ThemeProvider: MUI 컴포넌트들이 일관된 테마를 적용받을 수 있도록 함
• CssBaseline: 브라우저별 기본 스타일 차이를 제거하여 일관된 시작점 제공
• SnackbarProvider: 전역 알림 기능을 제공하여 컴포넌트들이 알림을 표시할 수 있도록 함

이러한 Provider들 없이는 테스트 중인 컴포넌트들이 필요한 컨텍스트를 찾지 못해 오류가 발생하거나 예상과 다르게 동작할 수 있습니다.

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

각 함수는 테스트용 Mock 서버에서 CREAT,UPDATE,DELETE 기능을 담당합니다.

• setupMockHandlerCreation: 새로운 이벤트를 생성할 때 사용. 단일 이벤트뿐만 아니라 여러 이벤트를 직접 추가할 수 있어, 초기 데이터 설정이나 빈 상태(일정이 없는 상태)에서의 테스트에 활용합니다.
• setupMockHandlerUpdating: 기존 mockEvents 데이터를 기준으로 수정 작업을 처리. 기존 일정 데이터가 있는 상태에서의 기존 데이터의 업데이트 테스트에 활용합니다.
• setupMockHandlerDeletion: mockEvents에서 특정 이벤트를 삭제. 삭제 후의 상태 변화를 확인하는 테스트에 활용합니다.

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

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

beforeEach에서 이 설정들을 사용하여 모든 테스트가 동일한 조건에서 실행되도록 일관성을 보장합니다.

• vi.setSystemTime: 시스템 시간을 고정하여 Mock 데이터와 날짜 비교 시 항상 동일한 테스트 결과를 얻을 수 있습니다. 실제로 시간 설정 없이 테스트하면 실행 날짜에 따라 결과가 달라질 수 있어 불안정한 테스트가 됩니다. 실제로 챕터2 진행시 화요일이 아닌 날에는 테스트가 통과되지 않는 이슈가 발생됐었습니다.
• expect.hasAssertions: 모든 테스트에서 반드시 expect를 사용한 검증이 이루어지도록 강제하는 규칙을 설정합니다. 검증 없이 통과하는 무의미한 테스트를 제한합니다.

심화 과제

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

과제 셀프회고

기술적 성장

테스트 코드를 처음 접했는데 이제 많이 친해졌습니다. 특히 비동기/동기 테스트 방식의 차이점, API 요청을 Mock 데이터로 처리하는 방법, 그리고 다양한 테스트 메서드들의 사용법과 차이점을 이해하게 되었습니다. toBe는 참조 비교와 원시값 비교에 사용하고, toEqual은 객체의 내부 내용까지 깊은 비교를 할 때 사용한다는 점을 배웠습니다. queryByTestId는 요소가 있을지 없을지 모를 때 사용하며 null을 반환하고, getByTestId는 반드시 존재할 것으로 예상되는 요소에 사용한다는 차이점도 알아냈습니다.

테스트 코드 첫 만남인데 너무 재밋고 어렵고 신기했습니다. 저한텐 유니콘🦄 같은 존재였는데 실제로 만나서 뿔도 만져보고 말도 걸어보고 생김새를 관찰해본 느낌이었습니다. 관찰해본 후기라고 한다면 아직은 재밋고 흥미진진한데 주변 사람들은 다들 재미없어해서 멋쩍은 느낌입니다. 왜 다들 재미없는지 유추해보자면 테스트 코드는 기획, UX적인 측면에서 고려해야할 것이 많고 그 부분을 코드로 풀어야 하다보니 UX와 친하지 않다면 코드를 짤 때마다 고될 것 같습니다.

코드 품질

노력한 부분

• test description를 기획 친화적으로 풀어서 상세하게 적으려고 노력했습니다.
• timeValidation.ts에 함수에 전달되는 인자가 string 원시 타입이다보니 좀 더 명확한 로직이 필요하다고 생각되어 테스트 코드를 작성하다가 예외처리 로직을 추가했습니다. (regex로 string 포멧 확인 + 테스트 코드 추가)

리팩토링을 진행하면서 순수함수이거나 코드가 간결하고 짧을수록, 그리고 응집도가 높고 결합도가 낮은 코드일수록 테스트 코드 작성이 훨씬 수월하다는 것을 체감했습니다. 반면 통합테스트처럼 관리해야 할 상태가 많아지거나 기능이 복잡해질수록 테스트 코드의 복잡도도 함께 증가하며, 고려해야 할 부분이 많아져 놓치는 부분이 발생할 가능성도 높아진다는 점을 깨달았습니다. 테스트 목 데이터 관리에 대해서도 고민해보았습니다. 별도의 dummies.ts 파일로 분리하는 것을 고민했는데, 중복 사용되는 부분이 크게 없고 데이터양이 많지 않아서 한 파일 내에서 테스트별로 필요한 더미데이터를 확인하는 것이 가독성 면에서 더 좋다고 판단했습니다. 실제로 handlerUtils.ts내부에 목 데이터가 들어가있어 테스트 코드 작성시 매번 해당 파일로 이동하여 목 데이터를 확인하면서 진행했었습니다.

학습 효과 분석

가장 큰 배움은 TDD(Test-Driven Development)의 중요성을 느낀 것 입니다. UI를 기준으로 나중에 테스트 코드를 작성하는 것은 고민 할 것이 많아 너무 어려웠고, 완성된 기능에 대해 테스트를 만들다 보니 놓치는 부분들이 생겼습니다. 테스트 코드를 먼저 작성하고 그에 맞춰 개발을 진행하는 TDD 방식이 훨씬 효율적일 것 같다는 생각이 들었습니다. 특히 상세한 UX 기획서를 기준으로 테스트 코드를 작성한다면 훨씬 체계적이고 완성도 높은 테스트가 가능할 것 같습니다. 또한 개발자들이 왜 테스트 코드 작성을 싫어하는지도 이해하게 되었습니다. 이전 회사에서 백엔드 개발자가 테스트 코드의 중요성을 알고 홀로 도입했으나, 프로덕트 코드가 클린하지 않아 테스트 코드를 모두 통과했는데도 불구하고 크게 에러가 터진 적이 있었습니다. 프로덕트를 빠르게 개발한 후에 만드는 테스트 코드는 도입 의미가 희석될 수 있으며, 이 테스트 코드를 완벽에 가깝게 만들기 위해서는 상당한 시간 투자가 필요하다는 것을 과제하면서 또 다시 느꼈습니다.

과제 피드백

통합 테스트가 단위 테스트보다 훨씬 어렵다는 것을 실감했습니다. 여러 컴포넌트와 상태가 얽혀있는 상황에서 모든 케이스를 다 커버하려다 보니 테스트 코드가 복잡해지고, 예외 처리까지 상세하게 하려면 한눈에 보기 힘들어진다는 딜레마가 있었습니다. 테스트 코드도 클린 코드만큼이나 가독성이 중요하고 개인의 취향을 많이 타는 것 같아서, 팀 내에서 일관된 스타일 가이드나 방향성이 있다면 더 좋을 것 같다고 생각했습니다. 특히 테스트 코드를 처음 작성하는 입장에서는 명확한 가이드라인이 있었으면 더 체계적으로 접근할 수 있었을 것 같습니다.

리뷰 받고 싶은 내용

테스트 더미데이터 관리 고민 현재는 각 테스트 파일 내에서 더미데이터를 관리하고 있는데, 프로젝트 규모가 커질 때를 대비한 효과적인 테스트 데이터 관리 방법이 있는지 궁금합니다. 언제 분리하고 어떤 기준으로 구조화하는 것이 좋을까요? 이전 멘토링때 코치님께서 실무에서 더미데이터를 따로 분리해서 사용하시는 것을 보여주셨는데 그 방법이 실제로 괜찮은 방법이어서 채택됐는지 아니면 다른 방법도 있었는데 그렇게 바뀌게 된건지도 궁금합니다.

통합테스트 vs 단위테스트 비율과 전략 통합테스트가 단위테스트보다 작성하기 어렵고 복잡하다는 것을 경험했습니다. 실제 프로젝트에서는 이 둘의 적절한 비율이나 우선순위를 어떻게 정하는지, 그리고 통합테스트 없이 단위테스트만 진행할 경우 크게 문제가 있을까요? 테스트 코드를 작성하면서 일부 단위테스트의 내용이 통합테스트에도 비슷하게 사용되었는데 단위테스트에서 최대한 커버하고 통합 테스트에서는 딱! 단일 ui적인 부분만 테스트하면 되지 않을까..하고 상상해봤는데 맞는지 모르겠습니다!

---