8주차 과제 체크포인트

기본 과제

필수

• 반복 유형 선택
  • 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
  • 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
    • 31일에 매월을 선택한다면 -> 매월 마지막이 아닌, 31일에만 생성하세요.
    • 윤년 29일에 매년을 선택한다면 -> 29일에만 생성하세요!
• 반복 일정 표시
  • 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
    • 아이콘을 넣든 태그를 넣든 자유롭게 해보세요!
• 반복 종료
  • 반복 종료 조건을 지정할 수 있다.
  • 옵션: 특정 날짜까지, 특정 횟수만큼, 또는 종료 없음 (예제 특성상, 2025-06-30까지)
• 반복 일정 단일 수정
  • 반복일정을 수정하면 단일 일정으로 변경됩니다.
  • 반복일정 아이콘도 사라집니다.
• 반복 일정 단일 삭제
  • 반복일정을 삭제하면 해당 일정만 삭제합니다.

선택

• 반복 간격 설정
  • 각 반복 유형에 대해 간격을 설정할 수 있다.
  • 예: 2일마다, 3주마다, 2개월마다 등
• 예외 날짜 처리:
  • 반복 일정 중 특정 날짜를 제외할 수 있다.
  • 반복 일정 중 특정 날짜의 일정을 수정할 수 있다.
• 요일 지정 (주간 반복의 경우):
  • 주간 반복 시 특정 요일을 선택할 수 있다.
• 월간 반복 옵션:
  • 매월 특정 날짜에 반복되도록 설정할 수 있다.
  • 매월 특정 순서의 요일에 반복되도록 설정할 수 있다.
• 반복 일정 전체 수정 및 삭제
  • 반복 일정의 모든 일정을 수정할 수 있다.
  • 반복 일정의 모든 일정을 삭제할 수 있다.

심화 과제

• 이 앱에 적합한 테스트 전략을 만들었나요?

각 팀원들의 테스트 전략은?

저희팀은 팀원별로 테스트 전략에 대한 의견을 주고 받기 보다는 피그잼을 통해 함께 브레인스토밍하며 전략을 좁혀 나갔습니다.

• [9팀 테스트 전략 키노트](https://www.figma.com/board/dYGP9N0xBufQX0NiHFq0Rg/9%ED%8C%80?node-id=0-1&p=f&t=2jT1n4jmI1VUH04 Q-0)

따라서, 하나의 PR에 테스트 전략을 수립하여 모두 페어코딩을 진행했습니다. 결론적으로 9팀은 심화과제 PR부분과 코드 전략을 함께 작성하여 그 내용이 같습니다.

• 테스트 전략을 적용한 최종 코드 PR 바로가기

합의된 테스트 전략과 그 이유는 무엇인가요?

저희 9팀은 TDD 기반으로 반복 일정 기능을 구현하면서 윤년, 월말 날짜 등 다양한 엣지 케이스를 마주할 수 있다고 판단했습니다. 따라서 테스트 전략의 목표를 엣지 케이스를 최소화하는 것으로 잡고, 이를 검증하기 위한 방향을 고민했습니다.

이 과정에서 단순히 “어떻게 테스트할까” 라는 관점에 머무르지 않고, “어떻게 하면 코드를 테스트하기 좋은 구조로 만들까” 라는 질문에 집중했습니다. 코치님께서도 이 점을 강조해주셨고, 그 조언을 바탕으로 레이어를 먼저 추상화한 뒤, 테스트할 부분과 그렇지 않은 부분을 의도적으로 구분하여 선택적으로 검증하는 전략을 수립했습니다.

아키텍처 정의하기

[기존 구조]

• 역할 기반 디렉토리 구조
• 유닛 테스트 비중이 높음 (피라미드 구성)

뿐만 아니라 utils 디렉토리는 아래와 같은 서로 다른 역할과 관심사가 혼재하고 있었습니다.

• repeatEventUtils : 반복 일정의 다음 날짜를 계산하는 순수 계산 로직
• notificationUtils : 사용자에게 알림을 띄우는 UI 관련 사이드 이펙트
• eventUpdateUtils: 이벤트 관련 도메인 레이어

이처럼 역할이 다른 코드들이 한 폴더에 섞여있어 반복 일정 계산 로직을 구별하기 어려웠습니다.

[레이어 도출]

• 반복 일정의 엣지 케이스를 판단하는 핵심 로직은 대부분 repeatEventUtils 같은 순수 함수 안에 있다고 판단했습니다.
• 이 함수들을 사이드 이펙트가 있는 함수로부터 분리하여 레이어를 나눈다면 테스트가 쉬워질 것이라고 의견을 모았습니다. 이 부분을 도메인 유틸 레이어(repeat) 로 정의하고 기존에 작성한 유닛 테스트를 활용하기로 했습니다.
• 전략적 선택과 집중
  • 집중: "도메인 레이어" 에 유닛 테스트를 집중하기로 했습니다.
  • 선택: 도메인 로직 테스트에 집중하는 대신, 변경이 잦고 테스트 비용이 비싼 UI 관련 테스트의 비중은 낮추기로 결정했습니다.
  • 가정: msw 핸들러와 같은 라이브러리나 Date 객체, Javascript 내장 함수 관련 로직은 자체의 동작을 신뢰하기로 가정했습니다. 대신 API 요청/응답에 따라 앱이 어떻게 반응하는지를 검증하는 통합 테스트를 추가하기로 했습니다.

[새로운 레이어 구조] 관심사의 분리와 테스트 용이성이라는 두 가지 키워드로 다음과 같이 레이어를 세분화하고자 했습니다.

1. utils

repeat이라는 기능(feature)단위로 디렉토리를 묶고, 그 안에서 역할을 세분화 했습니다.

📦repeat
 ┣ 📜actions.ts       # 상태를 변경하는 로직 (도메인)
 ┣ 📜constants.ts     # 기능 관련 상수
 ┣ 📜formats.ts       # 문자열 포맷팅 등 (도메인/UI 보조)
 ┗ 📜helpers.ts       # 핵심 계산 로직 (순수 함수, 도메인)

2. test

📦repeat
 ┣ 📂e2e
 ┣ 📂integration
 ┗ 📂unit
 ┃ ┣ 📜actions.spec.ts
 ┃ ┗ 📜helpers.spec.ts

레이어 별 테스트 전략 수립

아키텍처가 명확하게 정의되니 코치님 말씀대로 각 디렉토리의 역할에 맞는 테스트 전략을 구체화 할 수 있었습니다.

반복 일정 생성에서는 기준에 맞는 일정 생성 및 엣지 케이스 판단이 중요합니다. 반면 UI 구현의 비중은 적습니다. 이를 테스트 전략에도 반영했습니다. 일정 생성과 기준에 맞는 일정일지 판단하는 함수의 유닛 테스트의 비중을 높였습니다. UI 구현을 검증하는 통합 테스트와 e2e테스트는 최소한의 사용성을 보장하는 정도로 최소화했습니다.

저희는 '전략적 선택과 집중' 원칙에 따라 테스트의 종류와 범위를 다음과 같이 결정했습니다.

[Unit Test] - 도메인 로직 (Domain Logic)

• 대상: utils/repeat/helpers.ts, utils/repeat/actions.ts
• 전략: 테스트의 절반 이상을 집중합니다. helpers의 순수 계산 함수들을 테스트하며 엣지 케이스를 검증하고, actions의 상태 변경 로직이 의도대로 동작하는지 확인합니다.
• 이유: 반복 일정을 생성함에 있어서 윤년, 월별 일수와 같은 예외적 케이스를 고려하는 것은 큰 비중을 차지합니다. 그에 따라 테스트의 비중도 가장 높습니다.

[Integration Test] - 계층 간 통합 (Layer Integration)

• 대상: UI 컴포넌트, API 레이어, 도메인 로직의 통합 동작
• 전략: MSW를 활용하여 API의 성공, 실패, 비정상 응답 등 다양한 시나리오에 따라 UI 상태와 도메인 로직이 올바르게 연동되어 동작하는지 검증합니다.
• 이유: "API 요청/응답에 따라 앱이 어떻게 반응하는가" 를 확인하는 것이 목적입니다. 실제 서버나 fetch 라이브러리를 테스트 하는 것이 아니라, 각 레이어들이 올바르게 통합되어 데이터의 흐름을 잘 처리하는지 확인하는 목적입니다.

[E2E Test] - 사용자 시나리오 (User Scenario)

• 대상: 반복 일정 폼 등록, 삭제
• 전략: "사용자가 반복 일정을 생성하고 저장할 수 있다" 와 같은 중요한 시나리오 위주로 검증합니다.
• 이유: UI는 변경이 잦고 테스트 유지보수 비용이 아이콘 및 이벤트 리스트를 추가하는 UI구현의 중요도가 적습니다. 따라서 사용자에게 최종적으로 전달되는 핵심 기능이 문제없이 동작하는지만을 보장하기로 "선택" 했습니다.

추가로 작성된 테스트 코드는 어떤 것들이 있나요?

(작성 필요)

▶ 유닛 테스트

1. actions.spec.ts

• expandEventsToNextOccurrences
  • 다음 날짜의 반복 일정 반환 여부 확인
  • weekly의 경우 다음 요일, 윤년의 경우 다음 윤년 반환 여부 확인 ex) expandEventsToNextOccurrences 윤년 체크

describe('expandEventsToNextOccurrences - yearly', () => {
  it('yearly(2/29) 이벤트는 다음 윤년 2/29로 확장되고 id에 날짜가 결합된다', () => {
    const events = [
      makeEvent({
        id: 'e3',
        title: 'Yearly',
        date: '2024-02-29',
        repeat: { type: 'yearly', interval: 1 },
      }),
    ];

    const now = new Date('2025-02-28T00:00:00Z');
    const expanded = expandEventsToNextOccurrences(events, now);
    expect(expanded).toHaveLength(1);
    expect(expanded[0].date).toBe('2028-02-29');
    expect(String(expanded[0].id)).toBe('e3:2028-02-29');
  });
});

• getNextDailyOccurrence, getNextWeeklyOccurrence, getNextYearlyOccurrence

  • 기준일에서 하루, 1주, 1년 이후의 날짜 반환 여부 확인
  • 윤년의 경우 다음 윤년 반환 여부 확인

• generateInstances

  • 범위 내 반복 일정 반환 여부 확인
  • 같은 요일, 31일, 윤년 체크

2. helpers.spec.ts

• getNextYearlyOccurrence: 2/29 시작, from=평년 → 다음 윤년 ex) getNextYearlyOccurrence가 다음 윤년을 정확히 반환하는지 확인

it('getNextYearlyOccurrence: 2/29 시작, from=평년 → 다음 윤년', () => {
    const base = dateStringToUtcDateOnly('2024-02-29');
    const from = dateStringToUtcDateOnly('2025-02-28');
    const next = getNextYearlyOccurrence(base, from, 1);
    expect(toDateStringUTC(next)).toBe('2028-02-29');
});

• getNextMonthlyOccurrence: 1/31 시작, from=2월 → 3/31
• getNextWeeklyOccurrence: 수요일 시작, from=다음주 월요일 → 다음 수요일
• getNextDailyOccurrence: from이 더 뒤면 interval에 맞게 다음 날짜
• clampEndDate는 더 이른 날짜를 반환해야 한다
• daysInMonthUTC는 2월 윤년/평년과 30/31일을 정확히 반환해야 한다
• addMonthsUntilHasDay는 1/31에서 2월을 건너뛰고 3/31을 반환해야 한다

▶ 통합 테스트

1. 반복 UI 및 표시

• 반복 일정을 저장하면 캘린더 셀에 반복 아이콘(↻)이 표시된다 ex) 반복 일정 생성 후 캘린더에서 반복일정 아이콘 확인

it('반복 일정을 저장하면 캘린더 셀에 반복 아이콘(↻)이 표시된다', async () => {
    setupMockHandlerCreation();

    vi.setSystemTime(new Date('2025-10-15'));

    const { user } = setup(<App />);

    await user.click(screen.getAllByText('일정 추가')[0]);

    await user.type(screen.getByLabelText('제목'), '반복 회의');
    await user.type(screen.getByLabelText('날짜'), '2025-10-15');
    await user.type(screen.getByLabelText('시작 시간'), '09:00');
    await user.type(screen.getByLabelText('종료 시간'), '10:00');
    await user.type(screen.getByLabelText('설명'), '반복 테스트');
    await user.type(screen.getByLabelText('위치'), '회의실 C');

    await user.click(screen.getByLabelText('카테고리'));
    await user.click(within(screen.getByLabelText('카테고리')).getByRole('combobox'));
    await user.click(screen.getByRole('option', { name: '업무-option' }));

    const repeatToggle = await screen.findByLabelText('반복 일정');
    await user.click(repeatToggle);
    await user.click(await screen.findByRole('combobox', { name: '반복 유형' }));
    await user.click(screen.getByRole('option', { name: '매주' }));

    await user.click(screen.getByTestId('event-submit-button'));

    await user.click(within(screen.getByLabelText('뷰 타입 선택')).getByRole('combobox'));
    await user.click(screen.getByRole('option', { name: 'week-option' }));
    const weekView = within(screen.getByTestId('week-view'));
    expect(weekView.getAllByLabelText('반복 일정 아이콘').length).toBeGreaterThan(0);
});

• 반복 일정 체크 시 반복 유형/종료일 입력 UI가 노출된다
• 반복 일정을 단일 수정으로 저장하면 반복 아이콘이 사라진다
• 반복일정을 단일 삭제하면 해당 날짜 셀에서만 사라진다

▶ e2e 테스트

1. 기본 + 반복 아이콘

• 앱이 로드되고 기본 UI가 보인다
• 반복 일정 저장 시 캘린더 셀에 아이콘이 보인다

2. 단일 일정 삭제

• 단일 일정 삭제가 성공하고 화면에서 사라진다

ex) 일정 추가 버튼 -> 입력 -> 일정 겹침 경고 -> 반복 일정 등록 완료 -> 일정 삭제 -> 단일 일정 삭제 확인

test.describe('E2E - 단일 일정 삭제', () => {
  test('단일 일정 삭제가 성공하고 화면에서 사라진다', async ({ page }) => {
    await page.goto('/');

    const todayStr = (() => {
      const now = new Date();
      const yyyy = now.getFullYear();
      const mm = String(now.getMonth() + 1).padStart(2, '0');
      const dd = String(now.getDate()).padStart(2, '0');
      return `${yyyy}-${mm}-${dd}`;
    })();

    await page.locator('text=일정 추가').first().click();
    const uniqueTitle = `삭제 테스트 ${Math.random().toString(36).slice(2, 7)}`;
    await page.fill('input[id="title"]', uniqueTitle);
    await page.fill('input[id="date"]', todayStr);
    await page.fill('input[id="start-time"]', '09:00');
    await page.fill('input[id="end-time"]', '10:00');
    await page.locator('[aria-labelledby="category-label"]').click();
    await page
      .getByRole('option', { name: /개인|업무/ })
      .first()
      .click();
    await page.getByTestId('event-submit-button').click();

    const overlapDialog = page.getByRole('dialog', { name: '일정 겹침 경고' });
    if (await overlapDialog.isVisible().catch(() => false)) {
      await overlapDialog.getByRole('button', { name: '계속 진행' }).click();
    }
    await expect(page.getByText('일정이 추가되었습니다.')).toBeVisible();

    const beforeCount = await page.locator('button[aria-label^="Delete event"]').count();
    const beforeTitleCount = await page.getByText(uniqueTitle).count();

    const titleNode = page.getByTestId('event-list').getByText(uniqueTitle).first();
    const deleteBtn = titleNode
      .locator('xpath=ancestor::*[contains(@class, "MuiBox-root")][1]')
      .locator('xpath=.//button[starts-with(@aria-label, "Delete event")]');
    await deleteBtn.first().click();

    await expect(page.getByText('일정이 삭제되었습니다.')).toBeVisible();
    const afterTitleCount = await page.getByText(uniqueTitle).count();
    expect(afterTitleCount).toBeLessThan(beforeTitleCount);

    const afterCount = await page.locator('button[aria-label^="Delete event"]').count();
    expect(afterCount).toBe(beforeCount - 1);

    await expect(page.getByLabel('반복 일정 아이콘').first()).toBeVisible();
  });
});

---

과제 셀프회고

이번 테스트코드 7, 8주차 되게 재밌었습니다. 하나씩 퍼즐을 맞춰가는 느낌이랄까요. 다만 TDD는 생각보다 어려웠습니다. 처음 설명을 들었을 때는 되게 간단하게 느껴졌습니다. 테스트 코드(RED) 먼저 작성 후 최소한의 구현(GREEN), 이후 리팩토링(Refactor). 하나도 어려울 게 없어 보였습니다...만

우선 최소한의 구현이 생각보다 쉽지 않았습니다. RED를 1만큼 작성한 후 1만큼의 GREEN을 구현하려 했지만 이미 요구사항을 알고 있기에 자꾸 더 나아가 코드를 작성하게 되었습니다. 물론 요구사항을 인지하고 추가적인 방향까지 고려하며 개발하는 것이 나쁜 것은 아니지만 다음과 같은 본질을 놓치게 된다.

• 과도한 복잡성 조기 도입: 아직 필요하지 않은 추상화나 일반화를 미리 만들어버린다.
• 디버깅 범위 확대: 테스트가 실패했을 때 문제의 원인이 될 수 있는 코드 범위가 넓어진다.
• 리팩토링 타이밍 놓침: Green 단계에서 이미 "깔끔한" 코드를 작성했다고 생각하면 Refactor 단계를 건너뛰기 쉽다.
• 테스트와 구현의 결합도 증가: 한 번에 많은 기능을 구현하면 테스트가 구현 세부사항에 더 많이 의존하게 되어 나중에 리팩토링을 어렵게 만든다.
• 인지 부하 증가: 동시에 고려해야 할 것들이 많아져서 실수할 가능성이 높아지고, 각 결정의 영향을 정확히 파악하기 어려워진다.
• 학습 기회 상실: TDD의 진짜 가치는 작은 단계를 통해 얻는 통찰력인데, 이를 건너뛰면서 TDD의 진짜 장점을 체험할 기회를 놓치게 된다.

TDD를 성실히 이행하기 위해선 많은 연습이 필요할 것 같다. 기존에 개발하던 관성을 버리고 의식적으로 TDD 근육을 키울 필요가 있지 않을까 생각한다.

기술적 성장

우선 TDD를 처음으로 경험해 보았다. 그간 말로만 듣던 TDD, 역시 한 번이라도 해 보는 것이 중요하다. 더 이상 TDD라는 말이 엄청 크게 느껴지거나 낯설지는 않다. 만약 다음 회사에서 TDD로 개발한다고 하더라도 큰 두려움 없이 할 수 있지 않을까

두 번째로 2주 간의 테스트 코드 주차를 거치며 테스트 코드에 자신감이 생겼다. 어떤 단위로 테스트 코드를 나누어야 할지, 어떤 기능을 중점적으로 테스트해야 할지, 테스트 코드는 어떻게 작성하는지 알게 되었다.

코드 품질

const saveEvent = async (eventData: Event | EventForm) => {
    try {
      if (editing) {
        if (eventData.repeat.type !== 'none') {
          const copyData = { ...eventData } as Event;
          const repeatEvents = generateRepeatEvents(copyData);

          await deleteEvent(copyData.id);
          await addEvents([copyData, ...repeatEvents]);
        } else {
          // 반복 설정이 없으면 repeat 초기화해서 수정
          await updateEvent({ ...eventData, repeat: { type: 'none', interval: 0 } } as Event);
        }
      } else {
        if (eventData.repeat.type !== 'none') {
          // 기준 일정 + 추가 반복 일정들을 한 번에 생성
          const repeatEvents = generateRepeatEvents(eventData);
          const allEvents = [eventData, ...repeatEvents];

          await addEvents(allEvents);
        } else {
          await addEvent(eventData);
        }
      }

      await fetchEvents();
      onSave?.();
      enqueueSnackbar(editing ? '일정이 수정되었습니다.' : '일정이 추가되었습니다.', {
        variant: 'success',
      });
    } catch (error) {
      console.error('Error saving event:', error);
      enqueueSnackbar('일정 저장 실패', { variant: 'error' });
    }
};

이번에 급하게 짠다고 saveEvent를 그대로 사용하고 이 안에서 분기 처리 하였지만 saveEvent의 역할이 너무 무겁다고 생각한다.

리뷰 받고 싶은 내용

이번 테스트 코드를 비롯하여 항해에서 리액트도 직접 만들어 보고 클린 코드나 fsd도 배웠습니다. 하지만 이전 회사에서 사용해 보진 않았기에 이직 시 이를 어떻게 어필할 수 있을지 궁금합니다!