[9팀 신홍준] Chapter 🦍 3-1. 프론트엔드 테스트 코드 🦍

[jun17183]

과제 셀프회고

기술적 성장

코드 품질

학습 효과 분석

과제 피드백

리뷰 받고 싶은 내용

---

HARD

7주차 과제 체크포인트

기본과제

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

질문

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

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

심화 과제

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

과제 셀프회고

기술적 성장

그동안 과제를 진행하며 처음으로 테스트 코드를 마주했습니다. 처음에는 과제 통과만을 바라보다 보니 테스트 코드가 미웠지만, 항해 주차가 진행될 수록 테스트 코드에 의존하는 자신을 발견할 수 있었습니다. 그러던 중 테스트 코드가 없는 6주차 과제를 마주하였습니다. 세삼 테스트 코드가 그리웠습니다. 이젠 테스트 코드 없이 살 수 없는 몸이 되어버렸습니다.

이번에 처음 작성해 본 테스트 코드였지만, 되게 재밌고 잘 맞다는 느낌이 들었습니다. 잘 모르는 상태에서 떠올렸던 테스트 코드 철학이 실제로 테스트 코드에서 중요하게 다루는 가치였음에 기뻤고, 테스트 흐름에 따라 순차적으로 작성하는 것 또한 즐거웠습니다. 아마 앞으로 테스트 코드를 적극적으로 사용해 보지 않을까 생각합니다.

---

코드 품질

1. 이벤트 팩토리

테스트 코드는 그 자체로 독립적이어야 좋은 코드라고 생각했습니다. 이 생각은 멘토링과 QnA 시간을 통해 더욱 견고해졌습니다. 그래서 초기엔 다음과 같이 직접 하드코딩하여 테스트 데이터를 관리하였습니다.

const events = [
  {
    title: '...',
    description: '...',
    ...
  }
];

위와 같은 데이터를 매 코드마다 선언해 주어도 나쁘지 않다고 생각합니다. 다만 데이터 양이 많아지거나 속성이 너무 많으면 문제가 될 수 있다고 생각합니다. 테스트 코드 자체 만으로 독립적인 것도 중요한 가치지만, 결국 테스트 코드도 사람이 읽는 코드이기에 가독성을 위해선 어느 정도 타협이 필요하다고 생각했습니다.

처음엔 fixture 폴더를 만들어 모든 테스트에 적용할 수 있는 데이터를 만들었습니다. 하지만 하나의 데이터 목록으로 테스트를 커버하기엔 너무 많은 데이터가 필요하고, 이 과정에서 가독성이나 데이터 유지보수 또한 힘들어졌습니다.

다음으로 생각한 방법은 팩토리입니다. 처음에 추구하던 각 테스트만의 독립성을 보장하되, 과도한 속성이나 데이터 양을 커버하기에 팩토리가 안성맞춤이라고 판단했습니다.

import { Event, EventForm } from '../types';
import { generateEndTimeAfterStart, getRandomDate, getRandomTime } from './utils';

// 이벤트 폼
export const createEventForm = (override: Partial<EventForm> = {}): EventForm => {
  const startTime = getRandomTime();
  const endTime = generateEndTimeAfterStart(startTime);

  const defaults: EventForm = {
    title: `테스트 이벤트 ${crypto.randomUUID()}`,
    date: getRandomDate(),
    startTime,
    endTime,
    description: '',
    location: '',
    category: '',
    repeat: { type: 'none', interval: 0 },
    notificationTime: Math.floor(Math.random() * 60) + 1, // 1-60분
  };

  return { ...defaults, ...override };
};

// 이벤트 (id 포함)
export const createEvent = (override: Partial<Event> = {}): Event => {
  const eventFormDefaults = createEventForm();
  const defaults: Event = {
    id: override.id || crypto.randomUUID(),
    ...eventFormDefaults,
  };

  return { ...defaults, ...override };
};

// 목록
export const createEvents = (overrides: number | Partial<Event>[] = 0): Event[] => {
  if (typeof overrides === 'number') {
    return Array.from({ length: overrides }, () => {
      return createEvent();
    });
  }

  return overrides.map((override) => {
    return createEvent(override as Partial<Event>);
  });
};

위 팩토리를 통해 아래와 같이 코드를 간결하게 작성할 수 있었습니다.

it("검색어 '이벤트'와 주간 뷰 필터링을 동시에 적용한다", () => {
    const events = createEvents([
      { date: '2025-07-01', title: '이벤트' },
      { date: '2025-07-01', title: '검색어 제외' },
      { date: '2025-07-08', title: '이벤트' },
    ]);

    const expected: Event[] = [events[0]];

    const result = getFilteredEvents(events, '이벤트', new Date('2025-07-01'), 'week');

    expect(result).toEqual(expected);
    expect(result).toHaveLength(1);
});

handlers, handlersUtils

이벤트는 생성, 수정 되면 fetch를 다시 해 상태를 업데이트 합니다. 이를 위한 제어가 필요할 것 같은데요.
어떻게 작성해야 테스트가 병렬로 돌아도 안정적이게 동작할까요?
아래 이름을 사용하지 않아도 되니, 독립적이게 테스트를 구동할 수 있는 방법을 찾아보세요. 그리고 이 로직을 PR에 설명해주세요.

??
처음에 되게 의아했던 handlersUtils의 주석입니다. 그냥 느닷없이 handlers와 handlersUtils가 있으니 이게 어디에 쓰는 건지도 감이 잡히지 않았습니다. 우선 mock 폴더 안에 있으니 실제 서버 통신 대신을 위한 장치인 건 같은데,,, 왜 2개로 분리되어 있지...?

제 생각에 handlers는 여러 테스트를 전체적으로 흐름에 따라 진행하며 하나의 데이터를 바라보기 위함이고, handlerUtils는 병렬적으로 데이터를 관리하며 테스트를 진행하기 위함이라고 판단하였습니다.

그렇기 때문에 처음엔 handlers를 다음과 같이 작성하였습니다.

const data = { events: [ ...initialEvents ] }  // 전역

export handlers = [
  http.get( ... ),
  http.post( ... ),
]

그러고 handlersUtils는 클로저를 활용해 작성하려 했지만 handlers에 있는 서버 요청 코드 부분이 중복으로 필요했습니다. 이 부분이 마음에 들지 않아 다음과 같이 수정하였습니다.

export const createHandler = (initialEvents: Event[] = []) => {
  const data = {
    events: initialEvents.length > 0 ? initialEvents : [...events],
  };

  return [
    http.get('/api/events', () => {
      return HttpResponse.json({ events: data.events });
    }),

    http.post('/api/events', async ({ request }) => {
      const eventData = (await request.json()) as EventForm;
      const newEvent = { id: crypto.randomUUID(), ...eventData };
      data.events.push(newEvent);

      return HttpResponse.json({ events: data.events }, { status: 201 });
    }),

    http.put('/api/events/:id', async ({ params, request }) => {
      const { id } = params;
      const eventIndex = data.events.findIndex((event) => event.id === id);
      if (eventIndex > -1) {
        const eventData = (await request.json()) as EventForm;
        data.events[eventIndex] = { ...data.events[eventIndex], ...eventData };
        return HttpResponse.json({ events: data.events[eventIndex] });
      }
      return HttpResponse.json({ message: 'Event not found' }, { status: 404 });
    }),

    http.delete('/api/events/:id', ({ params }) => {
      const { id } = params;
      data.events = data.events.filter((event) => event.id !== id);
      return HttpResponse.json({ events: null }, { status: 204 });
    }),
  ];
};

export const handlers: HttpHandler[] = createHandler();

덕분에 handlersUtils는 간단하게 작성할 수 있었습니다.

export const setupMockHandler = (initEvents: Event[] = []) => {
  const events = [...initEvents];
  const handlers = createHandler(events);
  server.use(...handlers);
};

추가로 아래와 같은 서버 에러를 전제로 한 테스트를 위한 handlers도 작성하였습니다.

describe('useEventOperations 500 Error', () => {
  beforeEach(() => {
    setupMockErrorHandler();
  });

  it("이벤트 로딩 실패 시 '이벤트 로딩 실패'라는 텍스트와 함께 에러 토스트가 표시되어야 한다", async () => {
    const { result } = renderHook(() => useEventOperations(true));

    await act(async () => {
      await result.current.fetchEvents();
    });

    expect(enqueueSnackbarFn).toHaveBeenCalledWith('이벤트 로딩 실패', { variant: 'error' });
  });

  it("네트워크 오류 시 '일정 삭제 실패'라는 텍스트가 노출되며 이벤트 삭제가 실패해야 한다", async () => {
    const { result } = renderHook(() => useEventOperations(true));

    await act(async () => {
      await result.current.deleteEvent('notExistEvent');
    });

    expect(enqueueSnackbarFn).toHaveBeenCalledWith('일정 삭제 실패', { variant: 'error' });
  });
});

export const createErrorHandler = () => {
  return [
    http.get('/api/events', () => {
      return HttpResponse.json({ message: 'Error' }, { status: 500 });
    }),

    http.post('/api/events', () => {
      return HttpResponse.json({ message: 'Error' }, { status: 500 });
    }),

    http.put('/api/events/:id', () => {
      return HttpResponse.json({ message: 'Error' }, { status: 500 });
    }),

    http.delete('/api/events/:id', () => {
      return HttpResponse.json({ message: 'Error' }, { status: 500 });
    }),
  ];
};

3. 순차적인 테스트

테스트 코드를 작성하며 느낀 점 중 하나는 이 코드가 정확하게 테스트하고 있지 않을 수도 있겠구나 싶은 점입니다. 그저 버튼을 누르고 목록의 length가 1 더 늘었음을 확인하면 되는 것이 아니라, 렌더링이 되었음을 확인하고, 버튼을 누를 상태임을 확인하고, 기존의 데이터와 비교하여 새로운 데이터가 추가되었음을 확인하여야 했습니다. 그래서 다음과 같이 꼼꼼하게 테스트를 작성하도록 노력하였습니다.

it('기존 일정의 세부 정보를 수정하고 변경사항이 정확히 반영된다', async () => {
    const events = createEvents([{ title: '기존 회의', date: todayDate }]);

    setupMockHandler(events);

    render(<RenderApp />);

    // App 렌더링 테스트
    await expect(screen.getByText('일정 보기')).toBeInTheDocument();

    // 수정 전 일정 1건 확인
    expect(await screen.findAllByTestId('event-item')).toHaveLength(1);

    const editButtons = screen.getAllByRole('button', { name: 'Edit event' });
    expect(editButtons).toHaveLength(1);

    const user = userEvent.setup();

    // 일정 수정 버튼 클릭
    await user.click(editButtons[0]);

    // 수정 폼 변경 확인
    expect(screen.getByRole('button', { name: '일정 수정' })).toBeInTheDocument();
    expect(screen.getByLabelText('제목')).toHaveValue('기존 회의');

    // 일정 수정 폼 입력
    await inputEvent(user, { title: '수정된 회의' });

    // 일정 수정 버튼 클릭
    await user.click(screen.getByRole('button', { name: '일정 수정' }));

    // 수정 후 일정 목록 확인
    const listItems = await screen.findAllByTestId('event-item');
    expect(listItems).toHaveLength(1);
    expect(listItems[0]).toHaveTextContent('수정된 회의');
  });

---

학습 효과 분석

우선 처음으로 테스트 코드를 작성해 보았다는 점이 가장 고무적입니다. 마냥 테스트 코드는 필요하다, 하지만 한 번도 해보지 않았다는 생각만 있었는데 이제는 테스트 코드를 작성할 수 있다고 말할 수 있을 것만 같습니다.

물론 테스트 코드 라이브러리와 같은 사용법은 당연하고 어떤 테스트 코드가 좋은 테스트 코드인지 더욱 공부하고 눈에 많이 익혀둘 필요가 있다고 느꼈습니다. 테스트 코드는 기존에 작성하던 코드들보다 한 줄 한 줄의 의미가 더욱 짙다고 느낍니다. 반대로 더욱 정답이 없기도 한 것 같습니다. 그렇기에 더욱 많이 경험하고 시야를 넓힐 필요가 있다고 생각합니다.

실무 적용 가능성은 매우 높다고 생각합니다. 다만 프론트엔트 테스트 코드 특성상 미리 작성해 두기는 어렵다고 생각합니다. 아무래도 최소한의 인터렉션은 가능한 수준까진 개발이 필요하기도 하며 실제 화면이 어떻게 나올지 예측하긴 쉽지 않기 때문입니다. 그럼에도 테스트 코드는 매우 필요한 존재라고 생각합니다. 실무에서 시간이 주어진다면 테스트 코드 작성에 많은 시간을 투자하고 싶습니다.

---

과제 피드백

심화 과제로 리팩토링을 해야 하는 부분이 너무 당혹스러웠습니다. 테스트 코드를 체화하는데도 많이 벅찼는데 리팩토링까지 해야 하니 양이 너무 많기도 하고 적응이 잘 되지 않았습니다.

하지만 ai 사용을 지양하며 직접 테스트 코드를 작성해 본 경험은 정말 뜻깊은 경험이었습니다. 단순 테스트 코드에 대한 기술적인 학습을 넘어 테스트 코드에 대한 두려움을 없애거나 실무에 적용해 보고 싶은 마음까지 얻을 수 있었습니다.

---

리뷰 받고 싶은 내용

handlers는 setupTests를 위해, 그리고 테스트 전체 흐름에 맡게 하나의 데이터를 다루기 위함이며, handlersUtils는 이 과정에서 병렬적으로 데이터를 다루며 테스트를 진행하기 위함이라고 생각합니다. 하지만 막상 테스트 코드를 작성하다 보면 handlers는 실제로 사용할 일이 없어 보이며 모두 handlersUtils로만 작성하게 되었습니다.

vitest와 같은 플러그인 사용 등과 같이 하나의 테스트만을 독립적으로 실행하는 경우가 되게 많다고 생각하는데, handlers를 사용하면 이전, 이후 테스트에 영향을 끼치게 되더라구요. handlers만을 사용한 병렬적이지 않은 테스트 코드는 언제 필요할까요? QnA 때도 대충의 설명은 들었지만 구체적인 예시를 몰라서 그런지 감이 잡히지 않습니다.

[Amelia-Shin]

이번주도 고생많으셨습니다~
팩토리 함수로 뺀거 너무 잘한거같아요 :)

[susmisc14]

안녕하세요! AI 코드 리뷰어입니다. 🤖
[HARD] 7주차 과제: 캘린더 서비스 테스트 Pull Request에 대한 리뷰를 완료했어요. 함께 코드를 더 발전시켜 볼까요?

Note

✨ 이번 PR 한 줄 요약
거대한 App 컴포넌트를 테스트 가능한 단위로 성공적으로 분리하고, 테스트 격리를 위한 Mock Handler 팩토리 패턴을 훌륭하게 적용하여 코드의 품질과 테스트 용이성을 극적으로 향상시켰습니다.

---

🎯 핵심 리뷰 요약

가장 중요한 개선 포인트부터 빠르게 확인해 보세요.

• Monolith 컴포넌트의 성공적인 분리: 거대한 App.tsx를 목적에 따라 명확하게 분리하여 응집도를 높이고 테스트 용이성을 극대화했습니다.
• 우아한 Mocking 전략: createHandler 팩토리 함수를 통해 반복적인 MSW 핸들러 코드를 추상화하고, 각 테스트의 독립성을 완벽하게 보장했습니다.
• 전문적인 테스트 데이터 관리: eventFactory를 도입하여 테스트 코드의 가독성과 유지보수성을 한 차원 높였습니다.
• [심화 질문] 공유 상태 테스트의 역할: handlers와 handlersUtils의 역할에 대한 질문에 명확한 사용 시나리오와 장단점을 제시합니다.

---

🔍 상세 리뷰

각 항목에 대한 구체적인 설명과 코드 예시를 준비했어요.

1. The Monolith Slayer: 아키텍처 개선의 교과서

• 👍 좋은 점: 600줄이 넘는 App 컴포넌트를 CalendarView, EventForm, EventList 등 작고 관리 가능한 단위로 분리한 것은 이번 과제의 핵심 목표를 완벽하게 달성한, 매우 훌륭한 리팩토링입니다. 각 컴포넌트는 이제 단일 책임을 가지며, 독립적으로 이해하고 테스트하기 훨씬 쉬워졌습니다.

• 💡 개선 제안: 현재 App 컴포넌트가 최상위 컨테이너로서 대부분의 상태와 로직을 자식에게 props로 전달하는 '상태 끌어올리기(Lifting State Up)' 패턴을 사용하고 있습니다. 이는 작은 앱에서는 훌륭한 선택이지만, 애플리케이션이 더 복잡해지면 Prop Drilling 문제로 이어질 수 있습니다.

• 🤔 이렇게 제안하는 이유: Prop Drilling이란 상태가 필요 없는 중간 컴포넌트들을 거쳐 여러 단계에 걸쳐 props를 전달하는 것을 말합니다. 이는 컴포넌트 간의 결합도를 높여 재사용성과 유지보수성을 저해할 수 있습니다. 지금 당장 수정할 필요는 없지만, 이런 구조의 장단점을 인지하고 React Context API나 Zustand 같은 상태 관리 라이브러리가 언제 필요한지 고민해보는 것은 좋은 아키텍처 설계 경험이 될 것입니다.

• 🗺️ 아키텍처 변화 (AS-IS vs TO-BE)

AS-IS: 거대한 단일 컴포넌트

graph TD
    A[App.tsx] --> B{All States};
    A --> C{All UI Rendering};
    A --> D{All Event Handlers};
    A --> E{All API Calls};

Loading

TO-BE: 책임이 분리된 컴포넌트 구조 (현재 구조)

graph TD
    subgraph App.tsx (Container)
        A[States & API Logic]
    end

    subgraph Children (Presentational)
        B[EventForm]
        C[CalendarView]
        D[EventList]
        E[OverlapDialog]
        F[NotificationStack]
    end

    A -- Props --> B;
    A -- Props --> C;
    A -- Props --> D;
    A -- Props --> E;
    A -- Props --> F;

Loading

이 구조는 관심사 분리(SoC) 원칙을 잘 따르고 있으며, 각 컴포넌트의 역할을 명확하게 만들어주었습니다. 정말 잘하셨습니다!

2. Mocking의 정석: createHandler 팩토리 패턴

• 👍 좋은 점: handlers.ts에 createHandler라는 팩토리 함수를 만들어주신 부분은 정말 인상 깊었습니다. 클로저(Closure)를 활용하여 각 테스트마다 격리된 데이터 저장소를 갖는 핸들러를 동적으로 생성하는 방식은 테스트의 독립성을 보장하는 가장 이상적인 방법 중 하나입니다. handlersUtils.ts의 setupMockHandler가 이 팩토리를 사용함으로써 코드가 간결해지고 의도가 명확해졌습니다.

• 💡 개선 제안: 현재 구조는 완벽에 가깝습니다. 여기서 한 걸음 더 나아가자면, 특정 테스트 시나리오를 위한 **사전 정의된 핸들러 셋(Handler Set)**을 만들어볼 수 있습니다. 예를 들어, '이벤트가 하나도 없는 상태'나 '특정 이벤트가 반드시 포함된 상태'를 위한 팩토리를 추가로 구성하는 것입니다.

• 🤔 이렇게 제안하는 이유: 테스트를 작성하다 보면 반복적으로 사용되는 특정 데이터 상태가 있습니다. 이 상태들을 setupMockHandlerForEmptyEvents(), setupMockHandlerWithSpecificEvent(event)와 같이 명시적인 함수로 만들어두면, 테스트 코드의 가독성이 더욱 향상되고 준비(Arrange) 단계가 간결해집니다.

• 💻 코드 예시 (AS-IS vs TO-BE)

AS-IS (현재도 매우 훌륭한 구조)

// src/__mocks__/handlersUtils.ts
export const setupMockHandler = (initEvents: Event[] = []) => {
  const events = [...initEvents];
  const handlers = createHandler(events);
  server.use(...handlers);
};

// test.spec.ts
beforeEach(() => {
  setupMockHandler(createEvents(5)); 
});

TO-BE (시나리오 기반으로 확장)

// src/__mocks__/handlersUtils.ts
// 기존 setupMockHandler는 그대로 두고, 추가로 만듭니다.
export const setupEmptyMockHandler = () => {
  server.use(...createHandler([]));
};

export const setupErrorMockHandler = () => {
  server.use(...createErrorHandler());
};


// test.spec.ts
describe('이벤트가 없는 경우', () => {
  beforeEach(() => {
    setupEmptyMockHandler(); // 의도가 더 명확해집니다.
  });

  it('"검색 결과가 없습니다."가 표시되어야 한다', () => {
    // ...
  });
});

3. handlers는 언제 필요할까? (질문에 대한 답변)

셀프 회고에서 남겨주신 질문에 대한 답변입니다.

handlers만을 사용한 병렬적이지 않은 테스트 코드는 언제 필요할까요?

결론부터 말씀드리면, 거의 사용하지 않는 것이 좋습니다. 각 테스트가 독립적으로 실행되는 것이 가장 이상적이며, 현재 setupMockHandler를 beforeEach에서 사용하는 방식이 99%의 상황에서 올바른 접근법입니다.

하지만 handlers를 통해 테스트 간 상태를 공유하는 것이 유용한 아주 특수한 시나리오가 존재하기는 합니다. 바로 여러 테스트 케이스가 하나의 사용자 시나리오(User Story) 를 구성하여, 순서대로 실행되어야만 의미가 있을 때입니다.

• 🤔 시나리오 예시: E2E(End-to-End) 테스트처럼 사용자의 긴 여정을 테스트할 때
  1. test 1: 사용자가 성공적으로 로그인한다. (API 상태 변경: 로그인됨)
  2. test 2: 로그인된 상태에서 새 일정을 생성한다. (API 상태 변경: 일정 추가됨)
  3. test 3: 생성된 일정이 목록에 잘 보이는지 확인한다.
  4. test 4: 해당 일정을 수정한다. (API 상태 변경: 일정 수정됨)
  5. test 5: 수정된 내용이 잘 반영되었는지 확인한다.
  6. test 6: 일정을 삭제하고 로그아웃한다.

이런 테스트는 이전 테스트의 결과(Side Effect)에 다음 테스트가 의존하기 때문에, server.resetHandlers()를 하지 않고 공유된 handlers의 상태를 계속 유지해야 합니다.

• ⚠️ 단점 및 주의사항:
  • 취약성(Fragile): 이전 테스트 하나가 실패하면 이후 모든 테스트가 연쇄적으로 실패합니다.
  • 순서 의존성: 테스트 실행 순서가 보장되어야 하므로 병렬 실행이 불가능합니다.
  • 디버깅의 어려움: 테스트 실패 시, 해당 테스트의 문제인지 이전 상태의 문제인지 파악하기 어렵습니다.

따라서 이러한 방식은 Vitest나 Jest 같은 단위/통합 테스트 프레임워크에서는 안티패턴으로 간주되는 경우가 많습니다. Cypress나 Playwright 같은 E2E 테스트 도구에서나 제한적으로 사용되는 패턴이니, 지금처럼 테스트 격리 원칙을 지키는 것이 훨씬 중요합니다.

---

🗺️ 전체 개선 로드맵 (우선순위 가이드)

피드백의 중요도 순서대로 정렬했어요. 높은 순위부터 차근차근 해결해 나가는 걸 추천해요.

• WARNING ⚠️: 당장 문제는 없지만, 앞으로의 유지보수를 위해 개선을 적극 권장해요.
  • Prop Drilling 인지하기: App 컴포넌트의 역할을 다시 한번 생각해보고, 더 큰 애플리케이션에서는 어떤 문제가 발생할 수 있을지 고민해보세요. React Context API가 좋은 대안이 될 수 있습니다.
• OPTIONAL 💡: 코드 품질을 한 단계 더 높이기 위한 제안이에요. 선택적으로 적용해 보세요.
  • 시나리오 기반 Mock Handler 추가: setupEmptyMockHandler 와 같이 특정 테스트 시나리오를 위한 유틸 함수를 추가하여 테스트 코드의 의도를 더 명확하게 만들어 보세요.
  • Test Data Factory vs Fixtures: 현재 eventFactory는 동적인 랜덤 데이터를 생성합니다. 특정 ID나 값을 가져야 하는 통합 테스트를 위해, 고정된 데이터를 제공하는 fixtures.ts 파일을 따로 만드는 것도 좋은 방법입니다.

---

🤔 한 걸음 더: 코드와 의도 돌아보기

PR 본문을 통해 테스트 코드에 대한 깊은 고민과 즐거움을 느낄 수 있었습니다. 특히 eventFactory를 직접 만드신 과정은 매우 인상 깊었습니다. 그 고민을 바탕으로 몇 가지 질문을 드립니다.

• 목표와 구현의 연결고리: 본문에 작성해주신 '테스트 코드의 독립성'이라는 목표는 createHandler와 setupMockHandler를 통해 훌륭하게 달성되었습니다. 혹시 이 목표를 달성하기 위해 클로저를 활용하는 방식 외에 다른 아키텍처(예: 클래스 기반 Mock Server)를 고민해보셨나요?
• 숨겨진 의도 파악: medium.integration.spec.tsx 파일에서 inputEvent라는 헬퍼 함수를 만드신 것을 발견했습니다. 반복적인 폼 입력 로직을 추상화하신 아주 좋은 시도입니다! 이를 통해 테스트 코드의 가독성이 크게 향상되었습니다.
• 스스로에게 던지는 질문:
  • "내가 만든 EventForm 컴포넌트는 useEventForm 훅과 너무 강하게 결합되어 있지는 않은가? 만약 다른 폼 상태 관리 로직을 사용하게 된다면 얼마나 많은 코드를 변경해야 할까?"
  • "Toss Frontend Fundamental의 응집도(Cohesion) 원칙 관점에서, useEventOperations 훅은 API 통신이라는 단일 책임을 잘 수행하고 있는가? 아니면 상태 관리 역할까지 너무 많이 하고 있는가?"
  • "이번에 만든 eventFactory는 테스트에 필요한 모든 엣지 케이스(예: 제목이 아주 긴 이벤트, 설명이 없는 이벤트)를 쉽게 생성할 수 있는가?"
  • "이 코드를 처음 보는 동료는 handlers.ts와 handlersUtils.ts의 관계를 명확히 이해할 수 있을까? 주석이나 파일 구조를 통해 더 개선할 수 있는 점은 없을까?"

---

📚 참고 자료

문제 해결에 도움이 될 만한 자료들을 모아봤어요.

🌐 추천 아티클

• Avoiding Prop Drilling in React
• Stop using factories for your test data (Kent C. Dodds의 글: Factory 패턴의 다른 관점을 제시하며, Fixture와의 차이점을 고민하게 해줍니다.)
• React 컴포넌트를 테스트하는 방법 (번역)
• MSW: Mock Service Worker 공식 문서 - Isolating Tests

---

이번 리뷰가 성장에 큰 도움이 되었으면 좋겠습니다! 테스트 코드에 대한 깊은 고민과 훌륭한 결과물에 박수를 보냅니다. 👏