[1팀 이은지] Chapter 3-1. 프런트엔드 테스트 코드

[angielxx]

Medium

7주차 과제 체크포인트

기본과제

Medium

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

질문

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

toastFn은 화면에 일시적으로 나타나는 작은 메시지인 토스트 알림을 표시하는 함수입니다. mock은 실제로 알림을 표시하지 않고 toastFn의 동작을 테스트에서 시뮬레이션하여, 함수가 올바른 인수로 호출되는지를 확인할 수 있게 합니다.

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

ChakraProvider로 컴포넌트를 감싸는 것은 의미가 있습니다. 이는 컴포넌트들이 Chakra UI의 테마, 스타일, 컴포넌트를 사용할 수 있도록 Chakra UI 컨텍스트를 제공합니다. 이는 컴포넌트가 의도된 디자인 시스템으로 올바르게 렌더링되도록 보장합니다.

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

handlersUtils의 use 함수들은 테스트 목적으로 모의 핸들러를 생성하고 관리하는 데 도움을 주는 유틸리티 함수입니다. 이 함수들은 API 요청이 테스트 중에 어떻게 가로채지고 응답되어야 하는지를 정의하는 데 사용될 수 있으며, 다양한 시나리오를 시뮬레이션하고 애플리케이션의 동작을 검증할 수 있게 합니다.

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

setupTests.ts 파일은 일반적으로 테스트 환경을 설정하는 데 사용됩니다. 특정 시간을 설정하는 것은 애플리케이션의 시간 의존적 로직에 영향을 미칠 수 있는 현재 날짜와 시간을 제어하여 일관된 테스트 결과를 보장하기 위해 수행될 수 있습니다.

심화 과제

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

과제 셀프회고

이번 주 과제는 시간 투자를 많이 하지 못했습니다. (핑계로 들리실 수 있겠지만..) 이번주까지 개발 기간이라 저번주 주말도 일하고, 월요일부터 금요일까지 모두 야근을 했습니다. T.T 테스트코드 챕터도 제가 기대했던 챕터 중 하나였는데..(물론 기대하지 않은 챕터가 한 개도 없습니다만..) 이번 과제를 제대로 해보지 못해서 아쉬움만 가득 남았습니다. 다음주는 이번주에 개발 마친 버전의 검증 기간이기 때문에 일이 여유로울 것이라 예상되어 다음 과제는 (부디) 열심히 해보겠습니다..! (이상 반성문이었습니다.)

기술적 성장

의미있는 테스트를 작성하고 테스트 코드를 기반으로 리팩토링 하는 것을 목표로 했습니다.

1. 의미있는 테스트 코드 작성하기
2. 테스트 주도 리팩토링하기: 테스트로 안전망을 구축한 후 리팩토링 진행

1. Mock을 통한 의존성 격리의 중요성

// WeekView가 의존하는 훅들을 모두 Mock 처리
vi.mock('../../hooks/useEventOperations', () => ({
  useEventOperations: () => mockUseEventOperations,
}));
vi.mock('../../hooks/useNotifications', () => ({
  useNotifications: () => mockUseNotifications,
}));

이렇게 의존성을 격리하니 WeekView 자체의 렌더링 로직만 순수하게 테스트할 수 있었습니다.

2. 순수 함수의 테스트

순수 함수로 만들어야 테스트가 용이하다는 것을 테스트를 작성하면서 체감했습니다. 입력과 출력이 같고 부작용이 없기 때문에 테스트가 예측 가능하고 안정적이었습니다.

그래서 컴포넌트를 분리하는 이유가 단순히 코드 정리 뿐만 아니라 테스트 가능성을 확보하는 것에 의미도 있다는 것을 깨달았습니다.

3. 테스트 코드 가독성에 대한고민

테스트 코드 자체가 문서가 될 수 있다는 점을 기반으로 테스트 코드만 읽어도 요구사항을 파악할 수 있도록 문서처럼 술술 읽힐 수 있는 깔끔한 가독성을 가져야한다고 생각했습니다.

초반에는 테스트 코드에 들어갈 변수들을 따로 분리하여 작성했지만 오히려 가독성이 좋지 않은 것같아 글처럼 한줄로 읽을 수 있도록 개선했습니다.

AS-IS

it('1월은 31일 수를 반환한다', () => {
    const testDate = getDaysInMonth(2025, 1);
    const expected = 31
    
    expect(testDate).toBe(expected);
  });

TO-BE

  it('1월은 31일 수를 반환한다', () => {
    expect(getDaysInMonth(2025, 1)).toBe(31);
  });

이렇게 분리된 변수없이 한 줄로 통합하니 글 처럼 한 줄로 읽기가 더 좋아졌습니다.

리뷰 받고 싶은 내용

테스트코드의 가독성 부분이 궁금합니다. 제가 가독성이 더 좋다고 개선한 부분이 진짜 가독성이 좋아진건지 코치님의 의견이 궁금합니다!

AS-IS

it('1월은 31일 수를 반환한다', () => {
    const testDate = getDaysInMonth(2025, 1);
    const expected = 31
    
    expect(testDate).toBe(expected);
  });

TO-BE

  it('1월은 31일 수를 반환한다', () => {
    expect(getDaysInMonth(2025, 1)).toBe(31);
  });