HARD

7주차 과제 체크포인트

기본과제

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

질문

Q. handlersUtils에 남긴 질문에 답변해주세요.

1. 각 테스트마다 독립적인 데이터를 사용한다.

각 테스트가 자신만의 events 배열을 가짐

export const setupMockHandlerCreation = (initEvents = [] as Event[]) => {
  // 원본 데이터를 깊은 복사로 격리
  const events = [...initEvents]; // 테스트마다 다른 데이터 사용을 위해
  
  // ... 핸들러 설정

2. 각 함수마다 등록된 핸들러를 초기화 한 후 새로운 핸들러를 설정한다.

// 기존 핸들러 초기화
server.resetHandlers();

server.use(
  // 새로운 핸들러 설정
);

이전 테스트의 핸들러가 다음 테스트에 영향을 줄 수 있고 다른 테스트에서 생성한 핸들러가 현재 테스트를 간섭할 수도 있으니 초기화 한다.

3. 클로저를 활용

export const setupMockHandlerUpdating = () => {
  // 이 함수만의 독립적인 events 배열
  const events = [
    createMockEvent(1, { title: '개발 공부' }),
    createMockEvent(2, { title: '회의' })
  ];
  
  server.use(
    http.get('/api/events', () => {
      return HttpResponse.json({ events }); // 클로저의 events
    }),
    
    http.put('/api/events/:id', async ({ request, params }) => {
      // ... 
      // 클로저의 events 배열 수정
      events[index] = { ...events[index], ...updatedEvent };
      return HttpResponse.json(events[index]);
    })
  );

• 함수 호출마다 새로운 스코프를 생성한다 setupMockHandlerCreation()이 호출될 때마다 새로운 events 배열 생성
• 핸들러가 스코프를 기억 MSW 핸들러들이 함수 실행 시점의 events 배열을 기억한다
• 독립적인 상태 보장 각 테스트가 자신만의 events 배열을 가지게 된다

따라서 테스트 들이 동시에 실행되어도 서로 다른 이벤트를 가지기에 병렬로 돌아도 안정적이게 동작한다.

Q. 테스트를 독립적으로 구동시키기 위해 작성했던 설정들을 소개해주세요.

MSW (Mock Service Worker) 설정

• 각 테스트마다 독립적인 API 응답 설정한다
• 테스트들이 동시에 실행되어도 서로 영향을 주지 않는다.

/* msw */
export const server = setupServer(...handlers); //가짜 서버 생성 하고 handlers에 정의된 API 등록

beforeAll(() => {
  server.listen(); // 서버 시작해서 요청 받을 준비
  vi.useFakeTimers({ shouldAdvanceTime: true }); // shouldAdvnceTime: true 로 설정하면 타이머가 자동으로 진행됨
});

beforeEach(() => {
  expect.hasAssertions(); //최소 하나의 assertion이 있는지 확인, assertion 없으면 테스트 실패
  vi.setSystemTime(new Date('2025-10-01')); // 원하는 시점으로 고정
});

afterEach(() => {
  server.resetHandlers(); //MSW 핸들러를 초기화
  vi.clearAllMocks(); //특정 테스트 케이스에서 사용된 mock 함수 초기화
});

afterAll(() => {
  vi.resetAllMocks(); //모든 테스트 케이스에서 사용된 mock 함수 초기화
  vi.useRealTimers(); // 타이머 가짜 환경 설정 종료
  server.close(); //서버 종료
});

심화 과제

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

과제 셀프회고

테스트 코드를 해본 적이 없었는데 이번에 처음 짜보게 됐습니다. 어차피 알아야 할 내용이고, 학습이 목적이니 그냥 hard로 도전했는데... 따라가려다가 가랑이 찢기는 줄 알았습니다.

유닛 테스트까지는 간단하고 괜찮았는데, timer 설정이라든가 통합 테스트의 초기 설정 부분은 정말 어려웠어요, 어디를 어떻게 손대야 할지 감도 안 잡히고 문서만 봐서는 이해가 안 되는 부분도 많아 손을 대기가 막막했습니다.

다행히 주변에 고수가 있어서, 이것저것 물어가며 겨우겨우 여기까지 진행했습니다. 윤우님 감사해요........

기술적 성장

MSW 더 알아보기

setupServer vs setupWorker

기존 과제에서는 setupWorker를 사용해서 mock 을 받아서 진행했다. 그런데 이번 과제는 setupServer 를 사용한거 같다. 둘의 차이는 뭘까?

• 테스트(Node 환경) → setupServer() 사용 (Jest, Vitest 같은 유닛테스트 환경)
• 브라우저 개발 환경 → setupWorker() 사용 (Service Worker 등록해서 fetch/XHR 가로채기)

용도 차이라는 건 알게 됐다. 그렇다면 지금은 setupWorker 설정이 없는거 같은데, 어떻게 화면에서 mock을 받아서 사용할 수 있는 걸까?

server.js

MSW의 setupWorker 대체재 같은 역할. 브라우저에서 직접 Service Worker를 등록해서 요청을 가로채는 대신, Node/Express 서버를 띄워서 /api/events 라우트를 가짜로 구현해두고 프론트엔드가 여기에 fetch/axios 요청을 보내는 구조다.

• 브라우저 → http://localhost:3000/api/events 요청
• Express mock 서버 → JSON 파일(realEvents.json) 읽고 응답
• 따라서 프론트에서는 실제 API가 없어도 "진짜처럼" 요청을 보낼 수 있다.

Express Mock 서버 vs Worker 의 차이도 궁금해서 찾아봄

• worker는 인메모리 → 새로고침 시 초기화, express는 진짜 띄운거라 파일(JSON)로 지속 가능
• server.js로 띄웠기 때매 외부 클라이언트 모두 호출 가능, worker는 해당 브라우저에서만

즉..실제 서버처럼 진짜 흉내를 낼 수 있다..

테스트 코드 문법

테스트 코드 작성하면서 자주 사용한 문법 위주로 정리

• toBe: "이것이 정확히 같은 것인가?"
• toEqual: "이것의 내용이 같은가?"

test('toBe vs toEqual', () => {
  const a = { value: 1 };
  const b = { value: 1 };

  expect(a).toEqual(b); // ✅ 통과: 내용이 같은지 확인 → 객체나 배열의 내부 구조 비교
  expect(a).toBe(b);   // ❌ 실패:  같은 객체(참조)인지 확인 → ===와 같은 역할
});

• within: 특정 DOM 요소 내부에서만 찾기

render(
  <div>
    <section aria-label="A"><p>apple</p></section>
    <section aria-label="B"><p>banana</p></section>
  </div>
);

const sectionA = screen.getByLabelText('A');
expect(within(sectionA).getByText('apple')).toBeInTheDocument();

// DOM 안에서 쿼리 범위를 제한할 때 사용
// 동일한 텍스트가 여러 곳에 있을 때 정확한 영역 지정 가능

• toHaveBeenCalledWith: 함수가 특정 인자로 호출되었는지 확인

const mockFn = jest.fn();
mockFn('hello', 42);

expect(mockFn).toHaveBeenCalledWith('hello', 42); // ✅
expect(mockFn).toHaveBeenCalledWith('bye');       // ❌

// mock 함수가 어떤 인자와 함께 호출되었는지 검증할 때 사용
// 호출 순서와 인자 조합을 정확히 테스트할 수 있음

• **vi.setSystemTime, vi.advanceTimersByTimeAsync **: 가짜 시간 설정

vi.useFakeTimers();
vi.setSystemTime(new Date('2025-01-01'));
// 현재 시간을 지정된 날짜로 설정

await vi.advanceTimersByTimeAsync(1000);
// 타이머 기반 코드에서 시간 강제 진행

코드 품질

테스트 코드를 해본 적이 없었기에 코드의 품질보다는 설명이 얼마나 정확한가? 모호한 표현은 없는가? 를 중심으로 검토했습니다. 또 누락된 테스트는 없는지, 의미 없는 테스트가 포함되어 있진 않은지를 살펴보며 보다 의미 있는 테스트로 방향으로 바꿔보는 것에 집중했습니다.

무의미한 테스트 생략

• getDaysInMonth

//유효하지 않은 월에 대해 적절히 처리한다 < 원래 문구
 it('월이 12를 초과하면 자동으로 다음 해로 넘어가서 계산한다 (2025년 13월 → 2026년 1월)', () => {
    const result = getDaysInMonth(2025, 13);
    expect(result).toBe(31);
  });

해당 테스트는 유틸함수 테스트 보다는 Date 객체에 대한 테스트로 느껴져 생략했습니다.

엣지 케이스 추가

• getWeeksAtMonth

it('평년(2025년)의 2월 28일로 끝나는 월의 주 단의 배열을 올바르게 처리한다', () => {
    const weeksAtMonth = getWeeksAtMonth(new Date('2025-02-28'));

    expect(weeksAtMonth).toEqual([
      [null, null, null, null, null, null, 1],
      [2, 3, 4, 5, 6, 7, 8],
      [9, 10, 11, 12, 13, 14, 15],
      [16, 17, 18, 19, 20, 21, 22],
      [23, 24, 25, 26, 27, 28, null],
    ]);
  });

윤년, 평년이 엣지 케이스라 생각되어 해당 테스트를 추가했습니다.

혼동의 여지가 있는 표현은 제거

• getWeekDates

before: 주의 시작(월요일)에 대해 해당 주의 전체 날짜들을 반환한다
after: 월요일에 대해 해당 주의 전체 날짜들을 반환한다

기존 문구의 "주의 시작(월요일)" 표현이 실제 반환 결과(일요일 시작)와 어긋나 혼동의 여지가 있어 "시작"이라는 표현을 제거했습니다.

모호한 표현 구체화

• fetchHolidays

before: 주어진 월의 공휴일만 반환한다
after: 2025년 3월의 공휴일만 반환한다

before: 공휴일이 없는 월에 대해 빈 객체를 반환한다
after: 공휴일이 없는 2025년 2월에 대해 빈 객체를 반환한다

• getUpcomingEvents

before: 이미 알림이 간 이벤트는 제외한다
after: 10시 0분을 기준으로 알림 시간이 범위에 있는 이벤트만 반환한다

before: 알림 시간이 아직 도래하지 않은 이벤트는 반환하지 않는다
after: 10시 15분을 기준으로 이미 알림을 보낸 이벤트는 제외한다

추상적인 설명보다는 케이스에 맞게 구체화했습니다.

학습 효과 분석

테스트를 작성할 때 고려할 기준

1. 비정상 데이터 (edge case)는 테스트할 것인가?

• 기준: 함수의 책임과 사용 맥락에 따라 달라진다

  • 예외 처리를 직접 담당하는 함수라면, 잘못된 입력(예: 음수, 빈 값, 잘못된 날짜 등)을 반드시 테스트해야 한다.

  • 상위 로직에서 입력이 보장되는 경우라면, 해당 함수에서는 정상 케이스만 테스트해도 무방하다.

Tip: 팀 내에서 "이 함수는 입력 유효성까지 책임지는가?"에 대한 합의가 있으면 좋음.

2. 검증 시 하드코딩할 것인가, 동적으로 검사할 것인가?

• 기준:

  • expect(result).toHaveLength(3)처럼 고정된 숫자를 쓰면, 테스트가 명확하고 의도가 분명하게 드러남.

  • expect(result).toHaveLength(events.length)처럼 mock 데이터에 의존하면, 테스트의 유연성은 생기지만 테스트 자체의 의미가 약해질 수 있음.

• 추천:

  • 단순한 유닛 테스트 → 하드코딩된 숫자를 사용해 의도를 명확히

  • 복잡한 동적 데이터나 조건부 결과 → mock 데이터 기반으로 유연하게

3. 테스트 설명은 범용적으로 vs 구체적으로?

• 기준:

  • 범용 설명: 기능의 일반적인 동작을 설명할 때 사용 예) 입력한 날짜 기준으로 주간 일정을 반환한다

  • 구체적 설명: 특정 입력값과 기대 결과를 명확히 보여주고 싶을 때 사용 예) 2025-07-01을 입력하면 월요일부터 일요일까지 반환한다

• 추천:

  • 구체화할 수 있는 케이스는 구체화 해서 적기

과제 피드백

• 테스트 코드를 처음 작성하는 사람도 쉽게 따라갈 수 있도록 가이드가 잘 되어 있어 배우기 수월했습니다!
• 특히 난이도를 선택할 수 있는 점이 부담을 줄이는 데 도움이 되어 좋았습니다.

저는 배움의 목적으로 hard를 선택했는데 확실히 hard는 정말 막막하더라고요. 조금 더 가이드를 제공해도 괜찮지 않을까 싶습니다. 하다가 너무 어려워서 팀원의 힌트를 받아 작성했는데 힌트가 없었더라면 혼자서는 감을 잡기 어려웠을 것 같습니다.

리뷰 받고 싶은 내용

useNotifications 테스트 코드 작성 중에 시간 설정 관련해서 이해가 잘 안 되는 부분이 있어서 질문드립니다.

현재 setupTest.ts에서 전역으로 시간을 설정하고 있습니다

//setupTest.ts
beforeEach(() => {
  expect.hasAssertions(); //최소 하나의 assertion이 있는지 확인, assertion 없으면 테스트 실패
  vi.setSystemTime(new Date('2025-10-01')); // 원하는 시점으로 고정
});

그런데 useNotifications.spec.ts에서 알림 생성 테스트를 작성할 때 개별 테스트에서 시간을 다시 설정하지 않으면 테스트가 실패합니다

//medium.useNotifications.spec.ts

 // ? setupTest에서 설정을 했는데, 여기서 다시 설정을 하는거지? 근데 안하면 통과가 안된다.
  // > 시간까지 설정했더니 되네... 기존 2025-10-01에서 2025-10-01 00:00:00 으로 설정을 바꿨다.
  // > 이번엔 캘린더 훅 테스트에서 터짐... 그냥 여기서만 시간 설정하는 걸로...

  //그리고 shouldAdvanceTime: true 로 설정하면 타이머가 자동으로 진행된다라는 말이 있던데, 왜 안 흐를까..

  beforeEach(() => {
    // 시간을 2025-10-01 00:00:00으로 설정
    vi.setSystemTime(new Date('2025-10-01 00:00:00'));
  });

• setupTest에서 2025-10-01 00:00:00로 바꾸면 해당 테스트는 통과하지만 다른 hook 테스트들이 실패합니다. 이런 경우 각 테스트 파일에서 개별적으로 시간을 설정하는 것이 올바른 방법일까요? 아니면 전역 설정을 조정하는 다른 방법이 있을까요?

• shouldAdvanceTime: true 옵션이 시간을 자동으로 흐르게 해준다고 이해했는데, 실제로는 advanceTimersByTimeAsync()를 수동으로 호출해야만 테스트가 통과했습니다. shouldAdvanceTime 옵션이 정확히 어떤 역할을 하는 건가요? 언제 수동으로 시간을 진행시켜야 하고 이 옵션만으로는 왜 충분하지 않은 건지 궁금합니다...

통합 테스트에서 타임존 이슈

it('notificationTime을 10으로 하면 지정 시간 10분 전 알람 텍스트가 노출된다', async () => {
  vi.stubEnv('TZ', 'UTC'); // 타임존 설정

  const events = [
    createMockEvent(1, {
      title: '마지막',
      date: '2025-10-01',
      description: '마지막 일정',
      startTime: '00:10',
      endTime: '00:20',
      notificationTime: 10, // 10분 전 알림
    }),
  ];

  setupMockHandlerCreation(events);
  renderApp();

  // 먼저 이벤트가 표시되는지 확인
  expect(await screen.findByText('마지막 일정')).toBeInTheDocument();

  act(() => {
    vi.advanceTimersByTime(1000); // 1초만 진행
  });

  // 알림이 하나만 있는지 확인
  expect(screen.getByText('10분 후 마지막 일정이 시작됩니다.')).toBeInTheDocument();
});

이 테스트에서만 시간이 9시간씩 차이남 -> 타임존 차이(9시간)로 생각되어 이 테스트에서만 vi.stubEnv('TZ', 'UTC') 설정

• 통합 테스트 진행중 notificationTime 테스트에서만 9시간 차이가 발생해서 vi.stubEnv('TZ', 'UTC') 설정이 필요했습니다. 왜 이 테스트만 타임존 문제가 생긴 걸까요...

• 시간 관련한 테스트 코드가 제일 이슈가 많았습니다. 타이머 관련 테스트를 작성할때 팁이 있을까요? 시간 관련 테스트가 복잡해서 효율적인 접근법을 알고 싶습니다.

테스트 코드 작성이 아직 익숙하지 않아서 제가 접근하는 방식이 맞는지 확신이 서지 않습니다. 조언 부탁드립니다!