HARD

7주차 과제 체크포인트

기본과제

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

질문

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

용도에 따라 개별적으로 분리되어있던 함수를 createMockHandlers라는 하나의 유틸리티 함수로 통합했습니다. 이 팩토리 함수는 클로저(Closure)를 활용하여, 각 테스트가 고유한 상태를 갖는 핸들러를 생성합니다.

export const createMockHandlers = (initEvents = [] as Event[]) => {
  let testEvents = [...initEvents];

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

    http.post('/api/events', async ({ request }) => {
      const event = (await request.json()) as Event;
      const newEvent = { ...event, id: crypto.randomUUID() };
      testEvents.push(newEvent);
      return HttpResponse.json(newEvent);
    }),

    http.put('/api/events/:id', async ({ request, params }) => {
      const event = (await request.json()) as Event;
      const { id } = params;
      testEvents = testEvents.map((e) => (e.id === id ? event : e));
      return HttpResponse.json(event);
    }),

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

  const getEvents = () => {
    return testEvents;
  };

  const reset = () => {
    testEvents = [...initEvents];
  };

  return { handlers, reset, getEvents };
};

[사용 예시]

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

[주요 구현]

• createMockHandlers(initialState): 초기 상태를 인자로 받아, 해당 상태에만 접근하는 핸들러 배열과 상태 제어 함수(reset, getEvents)를 반환합니다.
• handlers: 생성된 스코프의 상태를 조작하는 MSW 요청 핸들러 배열입니다.
• reset(): 핸들러의 상태를 initialState로 초기화하여 테스트 간 상태 오염을 방지합니다.
• getEvents(): 테스트 중 상태를 확인하고 검증(assertion)할 수 있도록 현재 상태를 반환합니다.

구현하기 전, 두 가지 접근 방식을 고려했습니다.

1. 독립적인 MSW 서버 인스턴스를 만든다.

[구현 방식]

export const createIsolatedTestServer = () => {
  const isolatedServer = setupServer();
  const testEvents: Event[] = [];

  isolatedServer.use(
    http.get('/api/events', () => {
      return HttpResponse.json([...testEvents]);
    })
    // ... 기타 핸들러
  );

  return { server: isolatedServer, events: testEvents };
};

[장점]

• 완벽한 격리를 보장하여 테스트 간 상호작용을 원천적으로 차단합니다.

[단점]

• 각 테스트마다 생성하고 관리해야 하므로 복잡성이 증가합니다.
• 테스트 스위트가 커질수록 성능 저하 및 오버헤드가 발생할 수 있습니다.

2. 클로저 활용한 상태 격리 (현재 방식)

핸들러를 생성하는 팩토리 함수 내에 상태를 지역 변수로 두어, 클로저를 통해 상태를 캡슐화하고 격리합니다.

[장점]

• 구현이 간단하고 직관적입니다.
• 기존 MSW 서버 인스턴스를 공유하기 때문에 성능 저하의 우려가 적습니다.
• 테스트별 독립적인 상태 관리가 가능합니다.
• 빠른 테스트 실행

[단점]

• 잘못 사용 시 메모리 누수 가능성

[선택 기준 및 트레이드 오프]

• 단순성과 실용성에 초점을 맞추었습니다.
• 클로저를 활용한 방법은 충분한 수준의 격리를 간단하고 직관적인 방법으로 구현할 수 있다고 판단했습니다. beforeEach와 afterEach 같은 테스트 생명주기 훅(hook)과 결합하여 명확한 패턴으로 사용한다면, 실수할 여지를 최소화하면서 테스트의 독립성을 효과적으로 확보할 수 있습니다
• 핸들러 생성과 등록을 명확히 분리하고자 했습니다.

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

1. Setup과 Teardown 적용

  let mockHandlers: ReturnType<typeof createMockHandlers>;

  beforeEach(() => {
    mockHandlers = createMockHandlers();
    server.use(...mockHandlers.handlers);
  });

  afterEach(() => {
    mockHandlers.reset();
    server.resetHandlers();
    vi.clearAllMocks();
  });

각 테스트가 이전 테스트의 상태에 영향 받지 않고, 항상 독립적인 환경에서 실행되도록 보장하기 위해 beforeEach와 afterEach 생명주기 훅을 다음과 같이 구성했습니다.

• beforeEach (각 테스트 실행 직전)

  • mockHandlers = createMockHandlers() 매 테스트가 시작되기 직전, createMockHandlers를 호출하여 고유한 내부 상태를 가진 완전히 새로운 목 핸들러 세트를 만듭니다. 따라서 이전 테스트에서 변경된 상태가 현재 테스트에 절대 영향을 줄 수 없습니다.
  • server.use(...) 생성된 핸들러를 MSW 서버에 적용하여 현재 테스트가 이 격리된 핸들러만을 사용하도록 설정합니다.

• afterEach (각 테스트 실행 직후)

  • mockHandlers.reset() 현재 테스트에서 사용한 핸들러의 상태를 명시적으로 초기화하여 리셋합니다.
  • server.resetHandlers() MSW 서버에 등록된 핸들러를 모두 제거하여 서버 인스턴스 자체를 깨끗한 상태로 되돌립니다.
  • vi.clearAllMocks() 모든 모의(mock) 함수의 호출 기록을 지워 다음 테스트의 호출 횟수 검증(assertion)이 정확하게 이루어지도록 합니다.

2. renderProvider

export function renderWithProvider(
  ui: ReactElement,
  options?: Omit<RenderOptions, 'wrapper'>
): RenderResult {
  return render(ui, {
    wrapper: ({ children }) => <Provider>{children}</Provider>,
    ...options,
  });
}

[사용 예시]

  it('이벤트 목록이 올바르게 렌더링된다', () => {
      renderWithProvider(<EventList {...defaultProps} />);

앞에서 언급한 생명주기 훅이 테스트 외부 환경(서버, 모킹)에 관련한 적용이라면, renderWithProvider는 테스트 대상 컴포넌트의 내부 실행 환경을 독립적으로 구성하는 역할을 합니다.

1. 일관된 렌더링 환경 제공

• 테스트하려는 컴포넌트(ui)가 실제 애플리케이션처럼 필요한 Provider (예: Redux, React Query, ThemeProvider 등) 내부에서 렌더링되도록 일관된 환경을 제공합니다.
• 이 유틸리티 함수 없이 어떤 테스트에서는 Provider를 감싸고, 다른 테스트에서는 감싸지 않는다면 테스트는 불안정해집니다. renderWithProvider로 모든 테스트가 동일한 환경에서 시작하는 것을 보장하여 예측 가능성을 높일 수 있습니다.

2. 상태(State)의 격리

• Provider는 보통 앱의 전역 상태(global state)를 다룹니다. 만약 여러 테스트가 하나의 공유된 Provider 상태를 사용한다면, 한 테스트에서 상태를 변경했을 때 다음 테스트에 영향을 미쳐 테스트의 독립성이 깨지게 됩니다.
• renderWithProvider는 각 테스트가 호출될 때마다 내부적으로 새로운 Provider 인스턴스를 생성합니다. 이 Provider가 상태 관리를 새로 생성하도록 구성되어 있기 때문에 각 테스트는 격리된 상태 저장소를 가지고 시작하게 됩니다.

3. 팩토리 패턴을 활용한 이벤트 데이터 생성

export const createTestEvent = (overrides: Partial<Event> = {}): Event => {
  const baseEvent = events.events[0];
  return { ...baseEvent, ...overrides } as Event;
};

• 반복되는 목 이벤트 생성의 중복을 줄이고자 팩토리 함수를 적용했습니다.
• createTestEvent 기본 이벤트 객체에 overrides를 적용하여 매번 새로운 테스트 데이터 인스턴스를 생성합니다.
• 각 테스트가 고유한 데이터를 사용하므로 테스트 간 상호 간섭 및 부작용을 방지합니다 (독립성 보장)
• 데이터 구조 변경 시, 팩토리 함수만 수정하면 모든 관련 테스트에 반영되어 유지보수에 용이합니다.
• 테스트 코드에서 데이터 생성의 복잡성이 줄어들어 테스트의 핵심 로직을 파악하기 용이합니다.

심화 과제

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

과제 셀프회고

저는 테스트코드에 대한 경험이 playwright 으로 유저 시나리오 몇 개 작성해본 경험과 유닛 테스트를 ai로 작성해본 경험 밖에 없었습니다. 그래서 이번 과제에서 적용보다는 용어, 개념 위주로 이해 먼저 하고 실습을 하고자 했습니다. 역시나 진도가 더디게 되었고, 처음에는 어떤 흐름으로 작성해야할지 감도 안잡혔습니다. e2e는 제가 사용자로서의 경험도 있기에 "어떤 흐름으로 작성하면 되겠다" 라는 감각이라도 있었지만, 단위 테스트는 그 로직의 흐름을 정확하게 이해해야 했고, 그 자체를 검증하는 로직을 생각하고 구현했다고 해도 그것에 대한 확신이 부족했습니다. 진행하면서도 "이게 과연 이 함수를 검증하는 테스트인가? 유의미한가?" 를 계속 생각했지만, 확신은 없어 어렵게 느껴졌습니다. 화요일에 오프코치님께서 주신 강의가 도움이 많이 되었지만 시간상 당장 필요한 부분만 띄엄띄엄 본 것이 아쉬웠습니다. 강의를 다 보면 정리가 될 것 같은데, 잘 이해되지 않은 상태에서 테스트 코드를 작성한 것이 아쉬웠습니다.

기술적 성장

테스트 코드를 작성하면서 새롭게 알게 된 개념들을 하나씩 정리했습니다.

React Testing Library & Jest 주요 개념 심화 정리

1. describe

• Jest 공식 문서에 따르면 describe는 "함께 테스트할 관련 테스트들을 그룹화하기 위한 블록"을 생성합니다. 그룹화된 테스트들은 describe 블록이 실행될 때 하나의 컨텍스트를 공유합니다.

[예시]

describe('로그인 폼 테스트', () => {
  it('폼 요소들이 올바르게 렌더링되어야 한다', () => {
    // 테스트 코드...
  });

  it('폼 제출 시 유효성 검사를 통과해야 한다', () => {
    // 테스트 코드...
  });
});

• describe는 여러 개의 테스트를 논리적으로 묶어주므로, 테스트 결과 보고서를 볼 때 가독성이 높아지고 실패한 테스트가 어떤 기능과 관련 있는지 쉽게 파악할 수 있습니다.

2. it / test

• Jest 공식 문서에서 it과 test는 서로의 별칭(alias)이며, 기능적으로 완전히 동일합니다.
• 권장 사용법: 관습적으로 describe 블록 안에서 it을 사용해 "it should do something"과 같은 영어 문장처럼 테스트 설명을 작성하는 경우가 많습니다. 하지만 test 키워드를 사용해 "test if..."처럼 명확하게 테스트를 정의하는 것도 좋은 방법입니다. 어떤 것을 사용하든 팀 내에서 일관성을 유지하는 것이 중요합니다.

3. renderHook

• React Testing Library는 컴포넌트 렌더링에 특화된 라이브러리지만, renderHook은 DOM 요소 없이 커스텀 훅의 로직만을 테스트할 수 있도록 특별히 제공되는 기능입니다. 훅의 반환값이나 상태 변화를 테스트하는 데 사용됩니다.
• 주요 용도: useSWR처럼 비동기 데이터 패칭 로직을 가진 훅이나, 복잡한 상태 관리 로직을 가진 훅을 테스트할 때 매우 유용합니다.

4. wrapper

• render 함수의 옵션으로 제공되는 wrapper는 테스트할 컴포넌트를 특정 컴포넌트로 감싸는 역할을 합니다. 특히 Context Provider나 ThemeProvider처럼 테스트 대상 컴포넌트가 특정 상위 컴포넌트에 의존하는 경우에 사용됩니다.
• 장점: wrapper 옵션을 사용하면 각 테스트 케이스마다 동일한 Provider를 반복해서 작성하는 불필요한 코드를 줄일 수 있습니다.

5. baseElement

• render 함수의 옵션 중 하나로, 쿼리를 검색할 DOM의 기본 요소를 지정합니다.
• 주요 용도: document.body가 아닌 특정 컨테이너 안에서만 요소를 찾아야 할 때 사용합니다. 예를 들어 모달이나 팝업 컴포넌트는 document.body의 직속 자식이 아닐 수 있으므로, 해당 컴포넌트가 렌더링되는 부모 요소를 baseElement로 지정하여 테스트할 수 있습니다.

6. toBe vs toEqual vs toStrictEqual

• Jest의 매처(Matcher)들은 값의 비교 방식에 따라 엄격도가 다릅니다.
  • toBe: 원시 타입(숫자, 문자열, 불리언)의 **동일성(===)**을 확인합니다. 객체는 메모리 주소까지 비교하기 때문에 다른 객체라면 내용이 같아도 실패합니다.
  • toEqual: 객체나 배열의 내용(값)을 재귀적으로 비교합니다. expect({ a: 1 }).toEqual({ a: 1 })은 통과하지만, expect({ a: 1 }).toBe({ a: 1 })은 실패합니다.
  • toStrictEqual: toEqual보다 더 엄격한 비교를 수행합니다. 객체의 내용뿐만 아니라 속성의 undefined 여부, 배열의 희소성(sparse array) 등까지 정확하게 비교합니다. 예를 들어, expect([1, undefined]).toStrictEqual([1])은 실패합니다.

7. act

• React 공식 문서에 따르면 act는 "렌더링 및 상태 업데이트와 관련된 모든 작업이 완료될 때까지 기다리도록 보장"하는 헬퍼 함수입니다. React는 내부적으로 여러 상태 업데이트를 배치(batch)하여 한 번에 처리하므로, 비동기 작업 후 UI가 업데이트될 때 act로 감싸주지 않으면 테스트가 불안정해질 수 있습니다.
• 핵심: render와 fireEvent 같은 React Testing Library 함수들은 이미 내부적으로 act로 감싸져 있기 때문에, 대부분의 경우 직접 act를 사용할 필요가 없습니다. 하지만 setTimeout, 외부 라이브러리의 비동기 함수, 혹은 사용자 정의 이벤트 핸들러 등 React 테스트 라이브러리 외부에서 발생하는 비동기 상태 변화를 테스트할 때는 명시적으로 await act(...)를 사용해야 합니다.

8. findBy...

• findBy는 비동기적으로 요소를 찾는 쿼리 함수입니다. Testing Library 공식 문서에 따르면 findBy 계열은 getBy 쿼리와 waitFor 유틸리티를 결합한 기능입니다.
• 특징:
  • Promise를 반환하며, 요소가 나타날 때까지 기다립니다.
  • 지정된 기본 타임아웃(1000ms) 내에 요소를 찾지 못하면 Promise가 reject됩니다.
• 주요 용도: API 호출 후 데이터가 화면에 나타나는 것을 기다리거나, 애니메이션이 끝난 후 UI가 변경되는 것을 테스트할 때 유용합니다.

테스트 작성 시 꼭 알고 있어야 할 기본 원칙

React Testing Library의 핵심 철학은 "사용자가 애플리케이션을 사용하는 방식과 테스트 코드가 비슷할수록, 더 높은 신뢰도를 얻을 수 있다"는 것입니다. 이 철학에 기반한 주요 원칙은 다음과 같습니다.

1. 사용자의 행동을 테스트하라 (Test User Behavior)

• 무엇을 할 것인가? 사용자가 버튼을 클릭하고, 폼에 내용을 입력하며, 화면에 특정 텍스트가 나타나는지 확인하는 것과 같이 사용자의 관점에서 테스트를 작성해야 합니다.
• 무엇을 피할 것인가? 컴포넌트의 내부 상태(예: useState의 값)나 특정 CSS 클래스 이름, 구현 디테일(div, span 등)에 의존하는 테스트는 피해야 합니다. 이런 테스트는 리팩토링 시 쉽게 깨지며, 유지보수 비용이 높아집니다.

2. 구현 세부 정보는 테스트하지 마라 (Don't Test Implementation Details)

• getByTestId는 최후의 수단으로 사용하고, 사용자에게 의미 있는 쿼리(ByRole, ByLabelText, ByText, ByPlaceholderText)를 우선적으로 사용하세요. 예를 들어, screen.getByRole('button', { name: /클릭/i })처럼 사용자의 접근성(accessibility)을 고려한 쿼리를 사용하면 자연스럽게 더 견고하고 유용한 테스트를 작성할 수 있습니다.

3. 작고 집중된 테스트를 작성하라 (Write Small, Focused Tests)

• 하나의 테스트(it 블록)는 하나의 특정 기능을 검증해야 합니다. 여러 기능을 한 테스트에 섞지 마세요.
• describe 블록을 활용하여 관련 테스트를 그룹화하고, 각 테스트는 명확한 하나의 목표를 가지도록 작성해야 합니다. 이렇게 하면 테스트 실패 시 원인을 파악하기 쉽고, 디버깅 시간을 단축할 수 있습니다.

4. 테스트 코드를 가독성 있게 작성하라

• 테스트 설명을 명확하게 작성하여 테스트가 무엇을 검증하는지 한눈에 알 수 있게 하세요.
• AAA 패턴(Arrange-Act-Assert)을 따르는 것이 좋습니다.
• Arrange: 테스트에 필요한 환경 및 데이터를 준비합니다. (render(), Mock 데이터 등)
• Act: 사용자의 행동을 시뮬레이션합니다. (fireEvent.click(), fireEvent.change(), userEvent.type())
• Assert: 기대 결과를 검증합니다. (expect().toBeInTheDocument())

코드 품질

리팩토링이 필요한 부분 (EventForm)

1. 문제 많은 props 개수와 복잡성

const defaultProps = {
    events: mockEvents,
    title: '',
    setTitle: vi.fn(),
    date: '',
    setDate: vi.fn(),
    startTime: '',
    endTime: '',
    description: '',
    setDescription: vi.fn(),
    location: '',
    setLocation: vi.fn(),
    category: '업무',
    setCategory: vi.fn(),
    isRepeating: false,
    setIsRepeating: vi.fn(),
    repeatType: 'none' as const,
    repeatInterval: 1,
    repeatEndDate: undefined,
    notificationTime: 10,
    setNotificationTime: vi.fn(),
    startTimeError: null,
    endTimeError: null,
    editingEvent: null,
    handleStartTimeChange: vi.fn(),
    handleEndTimeChange: vi.fn(),
    resetForm: vi.fn(),
    onSaveEvent: vi.fn(),
    onOverlapDetected: vi.fn(),
  };

• 극악스러운 EventForm의 props를 리팩토링에서 해결을 못했습니다..
• 상태값, 상태 설정 함수, 에러 상태, 이벤트 핸들러 등 다양한 타입 혼재되어 있습니다.
• 빈 문자열, null, vi.fn() 등 테스트용 기본값들이 섞여 있습니다.

2. 테스트별 Props 오버라이드의 복잡성

it('시간 유효성 검사 에러가 있는 경우 에러 토스트가 표시된다', async () => {
  renderWithProvider(
    <EventForm
      {...defaultProps}
      title="테스트 이벤트"
      date="2025-01-20"
      startTime="14:00"
      endTime="13:00"
      startTimeError="시작 시간은 종료 시간보다 빨라야 합니다."
      endTimeError="종료 시간은 시작 시간보다 늦어야 합니다."
    />
  );
  // ... 테스트 로직
});

• 테스트마다 props 설정이 달라 복잡함이 체감됩니다.

3. props 구조 변경 시 영향 범위

it('모든 정보가 올바르게 입력된 경우 일정이 저장된다', async () => {
  const validProps = {
    ...defaultProps,
    title: '새 이벤트',
    date: '2025-01-20',
    startTime: '10:00',
    endTime: '11:00',
    description: '테스트 설명',
    location: '회의실',
    category: '업무',
    notificationTime: 10,
  };

  renderWithProvider(<EventForm {...validProps} />);
  // ... 테스트 로직
});

[근본적인 문제]

• EventForm 컴포넌트 자체가 많은 props를 받도록 설계되어 있습니다. 이는 컴포넌트가 너무 많은 책임을 가지고 있음을 의미합니다.
• 깊은 컴포넌트 트리에서 props를 계속 전달하는 구조로 설계되어 있습니다.
• 각 테스트마다 필요한 props만 오버라이드하는 것이 복잡함을 유발합니다.

[개선 방향]

1. Props 팩토리 함수 도입

const createEventFormProps = (overrides: Partial<EventFormProps> = {}): EventFormProps => {
  const baseProps: EventFormProps = {
    events: [],
    title: '',
    setTitle: vi.fn(),
    date: '',
    setDate: vi.fn(),
    startTime: '',
    endTime: '',
    description: '',
    setDescription: vi.fn(),
    location: '',
    setLocation: vi.fn(),
    category: '업무',
    setCategory: vi.fn(),
    isRepeating: false,
    setIsRepeating: vi.fn(),
    repeatType: 'none',
    repeatInterval: 1,
    repeatEndDate: undefined,
    notificationTime: 10,
    setNotificationTime: vi.fn(),
    startTimeError: null,
    endTimeError: null,
    editingEvent: null,
    handleStartTimeChange: vi.fn(),
    handleEndTimeChange: vi.fn(),
    resetForm: vi.fn(),
    onSaveEvent: vi.fn(),
    onOverlapDetected: vi.fn(),
  };

  return { ...baseProps, ...overrides };
};

2. 시나리오별 props 헬퍼 함수

const createValidEventFormProps = (overrides: Partial<EventFormProps> = {}) => {
  return createEventFormProps({
    title: '새 이벤트',
    date: '2025-01-20',
    startTime: '10:00',
    endTime: '11:00',
    description: '테스트 설명',
    location: '회의실',
    category: '업무',
    notificationTime: 10,
    ...overrides,
  });
};

const createErrorEventFormProps = (overrides: Partial<EventFormProps> = {}) => {
  return createEventFormProps({
    title: '',
    date: '',
    startTime: '14:00',
    endTime: '13:00',
    startTimeError: '시작 시간은 종료 시간보다 빨라야 합니다.',
    endTimeError: '종료 시간은 시작 시간보다 늦어야 합니다.',
    ...overrides,
  });
};

const createEditModeEventFormProps = (editingEvent: Event, overrides: Partial<EventFormProps> = {}) => {
  return createEventFormProps({
    editingEvent,
    title: '수정된 이벤트',
    date: '2025-01-15',
    startTime: '09:00',
    endTime: '10:00',
    ...overrides,
  });
};

[예시 코드]

describe('폼 유효성 검사 및 저장', () => {
  it('필수 정보가 누락된 경우 에러 토스트가 표시된다', async () => {
    const props = createEventFormProps({
      title: '',
      date: '',
    });

    renderWithProvider(<EventForm {...props} />);

    const saveButton = screen.getByTestId('event-submit-button');
    fireEvent.click(saveButton);

    expect(await screen.findByText('필수 정보를 모두 입력해주세요.')).toBeInTheDocument();
    expect(props.onSaveEvent).not.toHaveBeenCalled();
  });

  it('시간 유효성 검사 에러가 있는 경우 에러 토스트가 표시된다', async () => {
    const props = createErrorEventFormProps();

    renderWithProvider(<EventForm {...props} />);

    const saveButton = screen.getByTestId('event-submit-button');
    fireEvent.click(saveButton);

    expect(await screen.findByText('시간 설정을 확인해주세요.')).toBeInTheDocument();
    expect(props.onSaveEvent).not.toHaveBeenCalled();
  });

  it('모든 정보가 올바르게 입력된 경우 일정이 저장된다', async () => {
    const props = createValidEventFormProps();

    renderWithProvider(<EventForm {...props} />);

    const saveButton = screen.getByTestId('event-submit-button');
    fireEvent.click(saveButton);

    await waitFor(() => {
      expect(props.onSaveEvent).toHaveBeenCalledWith(
        expect.objectContaining({
          title: '새 이벤트',
          date: '2025-01-20',
          startTime: '10:00',
          endTime: '11:00',
        })
      );
    });
  });
});

개선 효과와 기대 결과

1. 가독성 향상

• 각 테스트가 무엇을 검증하는지 한눈에 파악 가능해집니다.
• 복잡한 props 오버라이드 로직에 대해 해소가 가능합니다.
• 테스트의 핵심 검증 로직이 props 설정에 묻히지 않습니다.

2. 유지보수성 향상

• Props 변경 영향을 최소화하여 새로운 prop 추가 시 팩토리 함수만 수정
• 테스트 데이터에 일관성을 부여하여 모든 테스트에서 동일한 기본값을 사용합니다.
• 시나리오별 props 헬퍼 함수로 테스트 코드 중복 제거할 수 있습니다.

3. 확장성 향상

• 새로운 테스트 시나리오 추가가 용이합니다. (헬퍼 함수만 추가 하면 된다)
• 팩토리 함수 수정으로 모든 테스트에 반영(Props 구조 변경 대응)

학습 효과 분석

• 아직은 "이런거구나" 라기 보다는 "이런..걸까..?" 의 느낌이 강한 시간들이었습니다.
• 다음주 과제를 시작하기 전에 공식문서를 읽고 정리해보는 시간을 가진다면 다음 과제를 더 잘 소화할 수 있을 것 같습니다.

과제 피드백

• 테스트 코드 작성에 대해 난이도별로 체계적으로 이해할 수 있도록 구성된 과제라고 느껴졌습니다.
• 다만 pass 난이도가 높다고 느껴졌습니다.ㅠㅠ

리뷰 받고 싶은 내용

1. 제가 작성한 단위 테스트의 신뢰도가 높다는 것을 스스로 판단하는 지표를 세운다면 어떤것을 기준으로 생각해볼 수 있을까요?
2. 또한 신뢰도 있는 단위 테스트를 작성하기 위해서는 어떤것을 고려하면서 작성하면 좋을까요?
3. QnA 시간에 유의미한 단위테스트와 그렇지 못한 단위테스트에 대해 설명해주셨는데, 사실 구별을 잘 못하겠습니다. 단위 테스트 작성에 익숙해진다면 구별하기 어렵지 않은 것일까요? 초심자가 어떤 것을 위주로 공부하면 빠르게 감각을 익힐 수 있을까요?