[3팀 이가은] Chapter 🦍 3-1. 프론트엔드 테스트 코드 🦍

[tooth-is-silver]

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

---

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적인 부분만 테스트하면 되지 않을까..하고 상상해봤는데 맞는지 모르겠습니다!

---

[susmisc14]

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

Note

✨ 이번 PR 한 줄 요약
거대한 App 컴포넌트를 테스트 용이성이 높은 컴포넌트와 훅으로 성공적으로 분리하고, 견고한 단위/통합 테스트를 구축하여 코드의 신뢰성과 유지보수성을 크게 향상시켰습니다.

---

🎯 핵심 리뷰 요약

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

• 아키텍처 개선: 'God Component'였던 App.tsx를 목적에 따라 컴포넌트와 훅으로 분리한 것은 이번 과제의 가장 큰 성과입니다. 이는 테스트 용이성을 극적으로 향상시켰습니다.
• 테스트 데이터 관리: 테스트의 가독성과 유지보수성을 한 단계 더 끌어올릴 수 있는 '테스트 데이터 팩토리(Factory) 패턴' 도입을 제안합니다.
• 테스트 전략: 통합 테스트와 단위 테스트의 이상적인 균형에 대한 고민을 '테스팅 트로피(The Testing Trophy)' 개념을 통해 해결해 보세요.
• 테스트 가독성: it.skip과 같이 비활성화된 테스트 케이스는 그 이유를 명확히 문서화하여 팀의 혼란을 방지하는 것이 좋습니다.

---

🔍 상세 리뷰

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

1. 경이로운 리팩토링: God Component의 해체와 테스트 가능한 아키텍처 구축

• 👍 좋은 점: App.tsx 하나에 모든 상태, 로직, UI가 뒤섞여 있던 구조를 useEventHandlers, useCalendarView 같은 커스텀 훅과 EventForm, CalendarView 등의 프레젠테이셔널 컴포넌트로 완벽하게 분리해내셨습니다. 이 결정 덕분에 각 모듈을 독립적으로 테스트하고 유지보수하는 것이 매우 용이해졌습니다. 셀프 회고에서 "응집도가 높고 결합도가 낮은 코드일수록 테스트 코드 작성이 훨씬 수월하다"고 말씀하신 부분을 코드로 직접 증명해내셨네요.
• 💡 개선 제안: 현재 구조의 우수성을 명확히 이해하고, 앞으로도 이런 설계를 유지하기 위해 '응집도'와 '결합도'의 개념을 다시 한번 짚어보는 것을 추천합니다.
• 🤔 이렇게 제안하는 이유:
  • 높은 응집도 (High Cohesion): useEventOperations는 서버 통신만, useEventForm은 폼 상태 관리만 책임집니다. 이렇게 하나의 모듈이 하나의 책임만 갖게 되면 코드를 이해하고 테스트하기가 매우 쉬워집니다.
  • 낮은 결합도 (Low Coupling): EventList 컴포넌트는 이제 events 데이터가 어떻게 생성되고 관리되는지 알 필요 없이, 그저 props로 받은 데이터를 화면에 그리고 상호작용(수정/삭제)을 부모에게 알리기만 하면 됩니다. 이는 EventList의 재사용성을 높이고, App.tsx의 변경이 EventList에 미치는 영향을 최소화합니다.
• 💻 아키텍처 비교 (AS-IS vs TO-BE)

AS-IS: 하나의 거대한 App 컴포넌트

graph TD
    A[App.tsx]
    A --> B{State (useState)}
    A --> C{API Logic (fetch, etc.)}
    A --> D{UI Rendering (JSX)}
    A --> E{Event Handlers}
    A --> F{Side Effects (useEffect)}

Loading

TO-BE: 역할과 책임에 따라 분리된 구조

graph TD
    subgraph Components
        D1[EventForm]
        D2[CalendarView]
        D3[EventList]
    end
    subgraph Hooks
        B1[useEventForm]
        B2[useCalendarView]
        C1[useEventOperations]
        E1[useEventHandlers]
    end
    A[App.tsx] --> B1 & B2 & C1 & E1
    A --> D1 & D2 & D3
    B1 --> D1
    B2 & C1 --> D2
    C1 --> D3

Loading

이처럼 역할에 따라 모듈을 분리하는 것은 테스트 용이성을 높이는 첫걸음이자 가장 중요한 단계입니다. 훌륭한 리팩토링입니다!

2. 테스트 데이터 관리: 더 이상 하드코딩은 그만, '팩토리 패턴'으로 진화하기

• 👍 좋은 점: 테스트 케이스마다 필요한 데이터를 직접 정의하여 각 테스트의 독립성을 확보하려는 노력이 보입니다. "테스트별로 필요한 더미데이터를 확인하는 것이 가독성 면에서 더 좋다고 판단했다"는 고민은 매우 중요하고 좋은 출발점입니다.

• 💡 개선 제안: 프로젝트가 커질 것을 대비해, 반복적인 모킹(Mocking) 데이터 생성을 추상화하는 테스트 데이터 팩토리(Test Data Factory) 패턴을 도입해 보세요. 이 패턴은 테스트 코드의 가독성과 유지보수성을 극적으로 향상시킵니다.

• 🤔 이렇게 제안하는 이유:

  • 가독성 향상: createMockEvent({ title: '중요한 회의' })처럼 테스트에 필수적인 데이터만 명시하면, 이 테스트가 무엇을 검증하려는지 의도가 명확해집니다. 나머지 속성은 기본값으로 채워지므로 테스트 코드가 간결해집니다.
  • 유지보수 용이성: Event 타입에 새로운 필드(예: priority)가 추가될 때, 모든 테스트 파일을 수정할 필요 없이 팩토리 함수 한 곳만 수정하면 됩니다. 이는 수십, 수백 개의 테스트를 관리할 때 엄청난 시간 절약으로 이어집니다.

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

  AS-IS (medium.useEventOperations.spec.ts)

    it('이벤트 정보를 받아 기존 이벤트 배열에 정상적으로 저장이 된다', async () => {
      // ...
      const newEvent: Event = {
        id: '1',
        title: '새로운 회의',
        date: '2025-07-16',
        startTime: '12:00',
        endTime: '13:00',
        description: '새로운 팀 미팅',
        location: '회의실 D',
        category: '업무',
        repeat: { type: 'none', interval: 0 },
        notificationTime: 15,
      };
    
      // ...
    });
    ```

    
    TO-BE (테스트 유틸리티 파일에 팩토리 함수 생성)
    
```typescript
    // src/__tests__/utils/factory.ts
    import { Event } from '../../types';

    export const createMockEvent = (overrides: Partial<Event> = {}): Event => {
      return {
        id: 'default-id-' + Math.random(),
        title: '기본 제목',
        date: '2025-10-01',
        startTime: '10:00',
        endTime: '11:00',
        description: '기본 설명',
        location: '기본 위치',
        category: '업무',
        repeat: { type: 'none', interval: 1 },
        notificationTime: 10,
        ...overrides, // 여기서 필요한 속성만 덮어씁니다.
      };
    };
    ```


    (테스트 파일에서 사용)
    
```typescript
    // medium.useEventOperations.spec.ts
    import { createMockEvent } from '../utils/factory';

    it('제목이 다른 새로운 이벤트가 정상적으로 저장된다', async () => {
      // ...
      // 이제 이 테스트의 핵심인 'title'과 'description'만 신경쓰면 됩니다.
      const newEvent = createMockEvent({ 
        id: '1', 
        title: '새로운 회의',
        description: '새로운 팀 미팅',
      });
    
      // ...
    });
    ```


**3. 테스트 전략 수립: Kent C. Dodds의 '테스팅 트로피'를 아시나요?**
- **👍 좋은 점**: "통합테스트 vs 단위테스트 비율과 전략"에 대해 깊이 고민하고 질문해주신 점이 매우 인상 깊습니다. 이는 모든 개발자가 부딪히는 현실적인 고민이며, 이 고민 자체가 성장의 증거입니다.
- **💡 개선 제안**: 단위 테스트와 통합 테스트의 관계를 경쟁이 아닌 협력 관계로 바라보는 **'테스팅 트로피(The Testing Trophy)'** 모델을 소개해 드리고 싶습니다. 이 모델은 '얼마나 많은 비용을 들여 얼마나 큰 자신감을 얻을 것인가?'에 대한 훌륭한 가이드를 제공합니다.
- **🤔 이렇게 제안하는 이유**:
    - **단위 테스트(Unit Tests)**: 빠르고, 저렴하며, 특정 로직의 정확성을 검증합니다. `dateUtils`의 함수들이 대표적인 예시입니다. 하지만 각 부품이 정상이라고 해서 완성된 자동차가 잘 굴러간다는 보장은 없습니다.
    - **통합 테스트(Integration Tests)**: 여러 모듈(컴포넌트, 훅, API 등)이 함께 동작하는 것을 검증합니다. 사용자가 경험하는 실제 시나리오와 가장 가깝기 때문에 **가장 높은 ROI(투자 대비 효과)**를 제공합니다. "일정 추가 버튼을 누르면, API 요청이 가고, 목록이 갱신된다"와 같은 시나리오를 테스트하는 것이죠.
    - 회고록에서 언급하신 "테스트 코드를 모두 통과했는데도 불구하고 크게 에러가 터진 적"이 바로 단위 테스트만으로는 부족한 부분을 통합 테스트가 채워주는 이유를 보여주는 완벽한 사례입니다.
- **💻 다이어그램: The Testing Trophy**
    

      /\\
     /  \\  <- E2E (가장 적게)
    /____\\
   /      \\
  /        \\ <- Integration (가장 많이, 핵심)
 /__________\\
/            \\

/ \ <- Unit (중간)
/________________\
/ \
Static Analysis (기본)
```

이 모델처럼, 대부분의 노력을 **통합 테스트**에 쏟는 것이 버그를 줄이고 안정적인 서비스를 만드는 데 가장 효과적입니다. 단위 테스트로 통합 테스트를 대체하는 것은 위험하며, "단위 테스트에서 최대한 커버하고 통합 테스트에서는 UI적인 부분만 테스트"하는 접근보다는, 사용자의 핵심 흐름을 검증하는 통합 테스트를 우선으로 작성하고, 복잡한 순수 함수 로직을 단위 테스트로 보충하는 전략을 추천합니다.

---

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

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

• CRITICAL 🚨: 현재 코드에는 심각한 버그나 문제는 보이지 않습니다. 훌륭해요!
• WARNING ⚠️: 테스트 데이터 팩토리 패턴을 도입하여 테스트 코드의 유지보수성을 확보하는 것을 적극 권장해요. 지금 당장은 괜찮지만, 프로젝트가 복잡해지면 기술 부채로 돌아올 수 있습니다.
• OPTIONAL 💡: it.skip으로 비활성화된 테스트(easy.eventUtils.spec.ts)에 대해, 왜 스킵했는지 주석(// 상위 테스트와 중복되어 비활성화)을 남겨두면 미래의 나 또는 동료가 코드를 이해하는 데 큰 도움이 됩니다.

---

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

PR 본문을 통해 깊은 고민을 엿볼 수 있었어요. 테스트라는 '유니콘'과 많이 친해지신 것 같아 저도 기쁘네요! 코드와 회고를 비교하며 몇 가지 질문을 준비했습니다.

• 목표와 구현의 연결고리: 본문에 "App 컴포넌트 적절한 단위의 컴포넌트, 훅, 유틸 함수로 분리"라는 목표를 완벽하게 달성하셨네요. 혹시 useEventHandlers 훅을 설계할 때, 어떤 로직까지 이 훅의 책임으로 둘지 고민했던 지점이 있나요? 예를 들어 findOverlappingEvents 호출을 useEventHandlers 내부에서 할지, 외부에서 결과를 받아올지 같은 결정들이요.
• 숨겨진 의도 파악: timeValidation.ts에 TIME_FORMAT_REGEX를 추가하여 시간 형식 자체를 검증하는 로직을 추가하셨더군요. 아마 테스트를 작성하시면서 발견한 엣지 케이스 같은데, 이런 디테일이 코드의 안정성을 크게 높입니다. 어떤 계기로 이 부분을 추가하게 되셨는지 궁금하네요!
• 스스로에게 던지는 질문:
  • 회고에서 TDD의 중요성을 느끼셨다고 했는데, 만약 useEventHandlers 훅을 TDD 방식으로 개발했다면 지금의 코드와 어떻게 달라졌을까요? 테스트 케이스를 먼저 상상해보는 연습을 해보는 건 어떨까요?
  • Toss Frontend Fundamental의 결합도(Coupling) 원칙을 보면 "어떤 모듈의 내용을 바꿨을 때 다른 모듈을 또 고쳐야 한다면, 그 둘은 강하게 결합되어 있다"고 말합니다. 지금의 구조에서 만약 notistack 라이브러리를 다른 알림 라이브러리로 교체한다면, 몇 개의 파일을 수정해야 할까요? 이 질문이 결합도를 측정하는 좋은 척도가 될 수 있습니다.
  • "이 코드를 처음 보는 동료는 handlerUtils.ts의 역할과 setupMockHandlerCreation 같은 함수들의 동작 방식을 쉽게 이해할 수 있을까?"
  • 이번에 적용한 컴포넌트/훅 분리 아키텍처가 "반복 일정" 같은 더 복잡한 기능이 추가될 때도 유연하게 확장될 수 있을까요?

---

📚 참고 자료

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

🌐 추천 아티클

• The Testing Trophy and Testing Classifications: 왜 통합 테스트가 중요한지에 대한 Kent C. Dodds의 원본 아티클입니다.
• 자바스크립트 테스트에서 테스트 픽스쳐를 만드는 5가지 방법: 테스트 데이터 팩토리 패턴을 포함하여 테스트 데이터를 관리하는 다양한 전략을 소개합니다.
• 리팩토링 2판: God Object를 분해하는 다섯 가지 단계: 이번에 성공적으로 수행하신 God Component 리팩토링에 대한 심도 깊은 아티클입니다.

---

이번 리뷰가 성장에 도움이 되었으면 좋겠습니다! 테스트 코드에 대한 열정과 깊은 고민, 정말 훌륭합니다. 계속 나아가세요

[ldhldh07]

테스트 데이터 호출할 때 인덱스를 이용해서 어떤 데이터를 사용하는지 어렵지 않나 싶기도 했는데, 그 테스트 로직이 일관성이 있어서 읽으면 읽을수록 빠르게 흐름을 파악할 수 있어서 좋았습니다!

다양한 vitest 메소드 사용해주셔서 많이 배우고 갑니당

[ldhldh07]

데이터는 변수명을 명사로 하는게 좋다 생각합니다!

[tooth-is-silver]

앗 그렇네요 코드 봐주셔서 감사합니다 😊

[ldhldh07]

아 이거 이렇게 하는거였군요. 제꺼에 이상하게 해버렸네

[tooth-is-silver]

제가 이상하게 한 것일수도 ... 🥹