항해 플러스 7기 1주차

드엔트론프·2025년 10월 26일

항해플러스

목록 보기

1/9

들어가며

1주차가 시작됐다. 여러 밤 새벽에 자며 과제를 도전했는데, 결국 1주차 과제를 다 끝내지 못했다. 아쉽지만 어쩔수 있나? 2주차 발제가 시작되고 벌써 일요일이 다 지나가고 있지만 1주차 이해 안된 부분은 조금 더 살펴보고 있다. 못한 부분은 다시 작성해보고 ~

몰랐던 사실

발제 시간에 나왔을지도 모른다. 내가 딴생각 하고있을때 지나간지도 모른다. 내가 몇 번 훑어봤지만 그럼에도 지나갔을 수 있다.

Vitest import 없이 사용되는 이유

vite.config.ts 파일에 테스트 관련 정의된 부분에 global: true 는 vitest를 전역적으로 사용할 수 있게 해준다. 이 말은 import 문을 굳이 쓰지 않아도 된다는 말!

import react from '@vitejs/plugin-react-swc';
import { defineConfig } from 'vite';
import { defineConfig as defineTestConfig, mergeConfig } from 'vitest/config';

export default mergeConfig(
  defineConfig({ ~~ }),
  defineTestConfig({
    test: {
      globals: true,
      environment: 'jsdom',
      setupFiles: './src/setupTests.ts',
      coverage: {
        reportsDirectory: './.coverage',
        reporter: ['lcov', 'json', 'json-summary'],
      },
    },
  })
);

그래서인지 vitest랑 RTL이 어떤 차이인지 정확히 구분을 못하고 있었다. 이제야 대략적인 차이를 느꼈달까.

Solution과 내 코드 비교하기

과제를 다 끝내지 못해서 찜찜한 기분이었다.
그래서 2가지를 생각했다.

Solution을 참고하며 내가 짠 코드와 뭐가 다른지를 비교하기.
못 푼 부분은 혼자서 좀 더 풀어보기.

특히, 같은 팀원 한 분이 코드리뷰를 해주었는데 내가 짠 테스트코드에서 이상한(?)부분을 이야기해주셨다. 나도 그분의 말에 공감했다. 그래서, 내가 짠 이상한 부분 외에도 전체적으로 Solution과 내 코드를 자체 코드리뷰하며 내가 왜 그렇게 짰는지와 Solution을 비교해가며 이해해보려 한다.

DateUtils

// 내 코드
describe('getWeekDates', () => {
  it('주중의 날짜(수요일)에 대해 올바른 주의 날짜들을 반환한다', () => {
    const wednesDay = new Date('2025-10-22');
    const octorberFourth = getWeekDates(wednesDay);

    expect(isDateInRange(wednesDay, octorberFourth[0], octorberFourth[6])).toBe(true);
  });

// 솔루션
describe('getWeekDates', () => {
  it('주중의 날짜(수요일)에 대해 올바른 주의 날짜들을 반환한다', () => {
    const date = new Date('2025-07-09'); // 수요일
    const weekDates = getWeekDates(date);
    expect(weekDates).toHaveLength(7);
    expect(weekDates[0].toISOString().split('T')[0]).toBe('2025-07-06'); // 일요일
    expect(weekDates[6].toISOString().split('T')[0]).toBe('2025-07-12'); // 토요일
  });

나는 왜 저렇게 짰는가?
1. 테스트코드도 짧게 적으면 좋은 줄 알았다.
  a. 정의된 함수를 활용해서 하면 더 짧아지고, 함수를 잘 이해하고 사용하는구만! 하는 건줄 알았다.

** 위와 비슷한 테스트에서도 다 동일하게 작성했는데, 여기서 팀원분의 피드백이 있었다.

팀원: 그 코드에서 isDateInRange 를 통해 도출하는데, 그러면 isDateInRange 도 테스트를 해야하는거 아닌가요? 하지만 지금 작성하신건 getWeekDates 함수인데, 다른 함수도 테스트해야하는 테스트 코드 방식은 좋지 않은것 같아요.

팀원2: 저도 동의하는게, 그럼 만약 isDateInRange 의 내용이 달라진다면 작성한 위 단위 테스트 코드조차 내용이 달라질거거든요.

나: 아하..! 정말 그렇네요..!

배운점.
1. 위와같이 하나의 함수를 테스트 할 때는 그 테스트만 테스트하는게 좋다.
2. describe로 크게 어떤 행동(?)을 할 지 정의하고, 그 안에 테스트를 it를 통해 구현, expect 해 테스트한다.
3. (발제 내용에도 이미 있었다)

비슷한 내용이 계속 있지만 다시 인지할 겸 작성.

  // 내가 짠 부분
  it('연도를 넘어가는 주의 날짜를 정확히 처리한다 (연말)', () => {
    const lastDay = new Date('2025-12-31');
    const week = getWeekDates(lastDay);

    expect(formatWeek(week[0])).toBe('2026년 1월 1주');
    expect(formatWeek(week[6])).toBe('2026년 1월 1주');
  });

  // 솔루션
  it('연도를 넘어가는 주의 날짜를 정확히 처리한다 (연말)', () => {
    const date = new Date('2024-12-30'); // 월요일
    const weekDates = getWeekDates(date);
    expect(weekDates[0].toISOString().split('T')[0]).toBe('2024-12-29'); // 일요일
    expect(weekDates[6].toISOString().split('T')[0]).toBe('2025-01-04'); // 토요일
  });

그래, 가져와서 저렇게 비교하면 될 걸
나는 또 함수 이해 잘하는 놈인 척 하고 싶어 getWeekDates 를 테스트하는 코드에 formatWeek 를 사용했다 ㅎㅎ

eventOverlap

// 내가 짠 부분
describe('parseDateTime', () => {
  it('2025-07-01 14:30을 정확한 Date 객체로 변환한다', () => {
    expect(parseDateTime('2025-07-01', '14:30')).toEqual(new Date('2025-07-01T14:30:00'));
  });

// 솔루션
describe('parseDateTime', () => {
  it('2025-07-01 14:30을 정확한 Date 객체로 변환한다', () => {
    const result = parseDateTime('2025-07-01', '14:30');
    expect(result).toEqual(new Date('2025-07-01T14:30:00'));
  });

이건 동일하지만 변수로 빼냐 안빼냐의 차이
누군가 질문방에 답변한 글 중 인상깊던 부분이 있다.

그래, 명세의 역할을 한다면 더욱이 다른 사람이 읽기 쉬운 코드가 돼야하는거지. 라는 생각에 참고의 의미로 가져왔다.
(사실 이 부분도 1주차 발제 내용에 있었음)

  // 내가 짠 부분
  it('잘못된 날짜 형식의 이벤트에 대해 Invalid Date를 반환한다', () => {
    const wrongMockEvent = { ...mockEvents[0], date: '202001010' };

    expect(convertEventToDateRange(wrongMockEvent)).toEqual({
      start: new Date(NaN),
      end: new Date(NaN),
    });
  });

 // 솔루션
 it('잘못된 날짜 형식의 이벤트에 대해 Invalid Date를 반환한다', () => {
    const event: Event = {
      id: '5',
      date: '2025/07/01', // 잘못된 형식
      startTime: '14:30',
      endTime: '15:30',
      title: '잘못된 날짜 이벤트',
      description: '',
      location: '',
      category: '',
      repeat: { type: 'none', interval: 0 },
      notificationTime: 0,
    };
    const result = convertEventToDateRange(event);
    expect(result.start.toString()).toBe('Invalid Date');
    expect(result.end.toString()).toBe('Invalid Date');
  });

위와 동일한 생각이 들어 가져왔다.
좋다고 느끼는 부분
- 주석으로 // 잘못된 형식 을 표기해준 부분.
- expect에 명확히 Invalid Date 를 해준 부분.

생각

통과에 급급해 남의 코드 보고 그대로 베껴쓰려니 내 양심에 찔려 못헀다. (물론 남의 코드 보면서 작성에 참고는 했는데 그대로 쓰지는 않으려 함)
과제 제출이 금요일인데, 어떻게든 완성해보려 애썼는데 시간을 보니 새벽 5시였다. 2시간 자고 출근해서 정신 못차리고 일하는 나를 보며 이건 아니다 싶었다.

2-1. 내 성장도 중요한데, 돈 받고 일하면 일하는 값은 해야지... 충분히 컨디션 조절해가며 허투루 시간쓰지 말고 시간을 잘 분배해 써야겠다 싶었다. (근데 아직 1주차거 되새기고있음 망했네)

메이트 분들과 많은 동료들이 과제 시작하면서, 과제 중간에도, 과제 끝날쯤에도 수많은 정보를 던져준다. 이 정보의 홍수에 어떻게 헤엄쳐야할까? 안볼수도 없는것 같고, 다들 어째 이렇게 빨리 확인하고 과제하나 싶긴하다.
첫 PR은 조졌다 볼 수 있다. 왜냐면 다 끝내지도 못했는데 5시에 비몽사몽하며 PR은 작성해야겠다 싶어서 그냥 흐르는대로 적었기 때문. 막상 WIL 적고있으니 조금 더 보이는 것 같은데, 다음 PR은 잘 쓰고 싶다 !

썸네일: 오늘 먹은 옥수수 피자, 진짜 맛있음. 남기고 온게 아쉬움

드엔트론프

왜? 를 깊게 고민하고 해결하는 사람이 되고 싶은 개발자

다음 포스트

항해 플러스 7기 1주차