HARD

7주차 과제 체크포인트

기본과제

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

질문

Q. handlersUtils에 남긴 질문에 답변해주세요. // ! Hard // ! 이벤트는 생성, 수정 되면 fetch를 다시 해 상태를 업데이트 합니다. 이를 위한 제어가 필요할 것 같은데요. 어떻게 작성해야 테스트가 병렬로 돌아도 안정적이게 동작할까요? // ! 아래 이름을 사용하지 않아도 되니, 독립적이게 테스트를 구동할 수 있는 방법을 찾아보세요. 그리고 이 로직을 PR에 설명해주세요.

useEventOperations를 확인해보면 saveEvent, deleteEvent에서 처리 후에 fetchEvent를 통해 새로 이벤트를 불러오게 되는데요. 이 경우에 삭제, 수정, 추가 이벤트에 대한 테스트가 병렬로 처리되었을 경우에 데이터가 불안정할 것으로 판단되었습니다.

그래서

// setupMockHandlerUpdating - 수정 테스트용
export const setupMockHandlerUpdating = () => {
  const events: Event[] = [
    {
      id: '1',
      title: '수정테스트입니당',
      date: '2025-10-17',
      // ... 기본 데이터
    }
  ];

  server.use(
    http.put('/api/events/:id', async ({ params, request }) => {
      const updatedEvent = (await request.json()) as Event;
      const index = events.findIndex((event) => event.id === params.id);

      if (index === -1) {
        return new HttpResponse(null, { status: 404 }); 
      }

      events[index] = { ...events[index], ...updatedEvent };
      return HttpResponse.json(events[index]);
    })
  );
};

// setupMockHandlerDeletion - 삭제 테스트용  
export const setupMockHandlerDeletion = () => {
  const events: Event[] = [/* 삭제용 기본 데이터 */];
  
  server.use(
    http.delete('/api/events/:id', ({ params }) => {
      const index = events.findIndex((event) => event.id === params.id);

      if (index === -1) {
        return new HttpResponse(null, { status: 404 });
      }

      events.splice(index, 1); 
      return new HttpResponse(null, { status: 204 });
    })
  );
};

위와 같이 MSW 핸들러 자체의 구조를 개선했습니다. 기존에는 하나의 전역 배열을 여러 테스트가 공유하는 형태였다면, 이제는 각 핸들러 설정 함수가 호출될 때마다 완전히 새로운 배열을 생성하도록 변경했습니다. setupMockHandlerCreation 함수에서는 전달받은 초기 데이터를 방어적 복사를 통해 독립적인 배열로 만들고, 이 배열만을 사용하는 GET, POST 핸들러를 설정하도록 구현하였습니다.

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

위에서 핸들러를 변경한것에 추가적으로 setupTests.ts파일에서도 추가적으로 설정을 했는데요.

import { setupServer } from 'msw/node';
import '@testing-library/jest-dom';

import { handlers } from './__mocks__/handlers';

/* msw */
export const server = setupServer(...handlers);

beforeAll(() => {
  server.listen();
  vi.useFakeTimers({ shouldAdvanceTime: true });
});

beforeEach(() => {
  expect.hasAssertions();
  vi.setSystemTime(new Date('2025-10-15'));
});

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

afterAll(() => {
  vi.resetAllMocks();
  server.close();
  vi.useRealTimers();
});

각 테스트가 끝난 후 이전 테스트의 영향을 완전히 제거하는 것이라고 판단했습니다. 따라서 setupTests.ts 파일에서 테스트 생명주기를 체계적으로 관리하도록 설정했습니다. beforeAll 단계에서는 MSW 서버를 시작하고 FakeTimer를 활성화합니다. FakeTimer를 사용하는 이유는 시간에 의존적인 테스트들이 실행 환경에 관계없이 일관된 결과를 얻기 위해서입니다. 특히 shouldAdvanceTime 옵션을 true로 설정하여 타이머가 실제로 진행되도록 했습니다. (하위에서도 이 설정에 대한 언급이 있습니다)

beforeEach 단계에서는 두 가지 중요한 설정을 합니다. 첫째로 expect.hasAssertions()를 호출하여 모든 테스트에 최소 하나 이상의 assertion이 있도록 강제합니다. 이는 빈 테스트나 실수로 assertion이 없는 테스트를 방지하기 위함이지만, 비동기적으로 콜백이 있는 경우에 이를 실행하지 않고 넘어갈 수 있는 상황을 미리 차단하는 역할도 합니다. 예를 들어, Promise가 reject되거나 콜백 함수가 호출되지 않는 경우, 테스트는 성공으로 표시되지만 실제로는 우리가 의도한 검증 로직이 전혀 실행되지 않은 상태가 될 수 있습니다. expect.hasAssertions()를 사용하면 이런 경우 테스트가 실패하도록 하여 false positive를 방지할 수 있습니다. (이 부분도 하위에 내용정리 해두었습니다.) 둘째로 vi.setSystemTime을 사용하여 모든 테스트가 동일한 시간(2025-10-15)에서 실행되도록 고정합니다. 이렇게 하면 날짜나 시간에 의존적인 로직을 테스트할 때 환경에 관계없이 일관된 결과를 얻을 수 있습니다. 가장 중요한 부분은 afterEach 단계입니다. 여기서 server.resetHandlers()를 호출하여 이전 테스트에서 server.use()로 설정한 모든 MSW 핸들러를 기본 상태로 복원하도록 구현하였습니다. 또한 vi.clearAllMocks()로 모든 mock 함수의 호출 이력을 초기화하고, vi.clearAllTimers()로 타이머 상태를 정리하도록 했습니다.

마지막으로 afterAll 단계에서는 모든 mock을 완전히 리셋하고 MSW 서버를 종료한 후 실제 타이머로 복원합니다.

또한 실제 테스트 파일에서는 각 테스트 케이스마다 적절한 핸들러 설정 함수를 호출하여 독립적인 환경을 구성하도록 했습니다. useEventOperations 테스트에서는 새로운 이벤트를 저장하는 테스트에서 setupMockHandlerCreation([])을 호출하여 빈 배열로 시작하는 완전히 새로운 환경을 만듭니다. 이 테스트가 실행되는 동안 다른 어떤 테스트의 데이터도 영향을 주지 않습니다. 수정, 삭제등의 테스트에서도 마찬가지로 새로운 환경에서 동작할 수 있도록 구현하였습니다.

enqueueSnackbar와 같은 외부 라이브러리 함수들도 독립성을 보장해야 합니다. notistack 라이브러리를 mocking할 때 vi.fn()으로 생성한 mock 함수를 사용하고, 각 테스트 후 vi.clearAllMocks()로 호출 이력을 초기화했습니다.

심화 과제

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

과제 셀프회고

테스트코드는 언제 짜려고 해도 명확하게 해답이 있는 문제가 아니라서 어려운 것 같습니다. 그래도 이번주는 수월할줄 알았는데... 발표라는 복병이...! 우하하... 그래도 어째저째 쓰러지진 않고 잘 마무리했으니까 된 거 겠죠...? 과제중에 저에게 힘을 주신...준일님의 팬심덕분에 새벽에 잠이 죽겠는데도 이겨냈습니다...(진짜임,,,나에겐 고양이같은...팬이있다)

기술적 성장

1. test() vs it()

Jest를 통해서 테스트코드를 작성할때 test와 it이 존재함을 알게되었습니다. 이 둘은 어떻게 다른 것일까요?

Jest에서 test와 it은 기능적으로 완전히 동일한 함수입니다. 둘 다 개별 테스트를 정의하는 데 사용되며, 단지 alias 관계일 뿐입니다. 차이점은 스타일과 가독성, 그리고 팀의 컨벤션에 있습니다.

// 이 둘은 정확히 같은 함수를 가리킵니다
test('calculation works correctly', () => {
  expect(2 + 2).toBe(4);
});

it('calculation works correctly', () => {
  expect(2 + 2).toBe(4);
});

Jest 공식 문서에서 확인할 수 있듯이, test 메서드는 it으로도 aliased되어 있습니다. 내부적으로는 완전히 동일한 함수를 호출하므로 성능이나 기능상의 차이는 전혀 없습니다.

또한 두 함수 모두 Jest의 모든 기능을 동일하게 지원합니다.

// 둘 다 timeout 지원
test('async operation', async () => { /* ... */ }, 10000);
it('async operation', async () => { /* ... */ }, 10000);

// 둘 다 .only, .skip 등의 modifier 지원
test.only('focused test', () => { /* ... */ });
it.only('focused test', () => { /* ... */ });

// 둘 다 .each로 데이터 주도 테스트 지원
test.each([[1, 2, 3]])('parameterized test', (a, b, expected) => {
  expect(a + b).toBe(expected);
});

it.each([[1, 2, 3]])('parameterized test', (a, b, expected) => {
  expect(a + b).toBe(expected);
});

What is the difference between 'it' and 'test' in Jest?에 따르면, test와 it의 차이를 다음과 같이 설명합니다.

describe('UserService', () => {
  test('사용자 생성이 올바르게 동작한다', () => {
    const user = createUser('김철수', 'kim@example.com');
    expect(user.name).toBe('김철수');
  });

  test('잘못된 이메일로 사용자 생성 시 에러가 발생한다', () => {
    expect(() => createUser('김철수', 'invalid-email')).toThrow();
  });
});

test는 우선 함수명 자체가 "테스트"라는 목적을 분명히 하여 직접적이고 명확합니다.

반면에 it은 BDD(Behavior Driven Development) 스타일의 자연어적 표현입니다.

describe('UserService', () => {
  it('should create user with valid data', () => {
    const user = createUser('김철수', 'kim@example.com');
    expect(user.name).toBe('김철수');
  });

  it('should throw error when email is invalid', () => {
    expect(() => createUser('김철수', 'invalid-email')).toThrow();
  });
});

위 코드처럼 "it should..." 패턴으로 자연어에 가까운 표현이고, 요구사항을 테스트로 직접 번역하기 용이합니다.

describe('Calculator', () => {
  it('should add two numbers correctly', () => {
    expect(add(2, 3)).toBe(5);
  });
  
  it('should handle negative numbers', () => {
    expect(add(-1, 1)).toBe(0);
  });
});

영어에서는 it이 자연스럽게 읽힙니다: "Calculator should add two numbers correctly"

describe('계산기', () => {
  // 어색한 표현
  it('두 숫자를 올바르게 더해야 한다', () => {
    expect(add(2, 3)).toBe(5);
  });
  
  // 자연스러운 표현  
  test('두 숫자를 올바르게 더한다', () => {
    expect(add(2, 3)).toBe(5);
  });
});

한국어로 테스트를 작성할 때는 test가 더 자연스러운 경우가 많습니다.

// 일관성 있는 사용 (Good)
describe('AuthService', () => {
  test('로그인 성공 시 토큰을 반환한다', () => { /* ... */ });
  test('잘못된 비밀번호로 로그인 시 에러가 발생한다', () => { /* ... */ });
  test('토큰 만료 시 자동으로 갱신한다', () => { /* ... */ });
});

// 혼재된 사용 (Bad)
describe('AuthService', () => {
  test('로그인 성공 시 토큰을 반환한다', () => { /* ... */ });
  it('잘못된 비밀번호로 로그인 시 에러가 발생한다', () => { /* ... */ });
  test('토큰 만료 시 자동으로 갱신한다', () => { /* ... */ });
});

실제 프로젝트에서는 test, it 중 어떤 것을 사용해도 되지만, 팀의 상황과 컨벤션에 맞게 사용하는 것이 중요합니다. 앞서 말했듯 test와 it의 차이는 가독성에 있기 때문입니다.

결국 중요한 것은 test냐 it이냐가 아니라, 의미있고 명확한 테스트를 작성하는 것이라고 할 수 있습니다.

출처

• https://jestjs.io/docs/api#testname-fn-timeout
• https://stackoverflow.com/questions/45778192/what-is-the-difference-between-it-and-test-in-jest

2. expect.hasAssertions()

Jest의 expect.hasAssertions()은 주로 비동기 테스트에서 assertion이 실제로 실행되었는지 확인하기 위해 사용됩니다. 여기서 말하는 assertion은 우리가 테스트를 실행할 때 작성하는 expect().toBe(), expect().toEqual() 같은 검증 코드들을 의미합니다.

비동기 테스트에서 가장 위험한 상황 중 하나는 테스트가 통과했지만 실제로는 아무것도 검증하지 않은 경우입니다.

function fetchUserData(userId, callback) {
  if (userId > 0) {
    api.getUser(userId).then(user => {
      callback(user); // 정상 케이스만 callback 호출
    });
    // .catch()가 없어서 에러 시 callback이 호출되지 않음
  }
  // userId <= 0인 경우 callback이 전혀 호출되지 않음
}

// 이 테스트는 잘못 통과할 수 있음
test('fetchUserData handles invalid userId', () => {
  fetchUserData(-1, (user) => {
    expect(user).toBeNull(); // 이 assertion이 실행되지 않음
  });
  // Jest는 테스트 함수가 끝나면 성공으로 간주
});

테스트를 실행하면 'fetchUserData handles invalid userId'인 것처럼 보이지만 실제로는 assertion이 실행되지 않습니다. 그렇기 때문에 해당 테스트는 거짓된 테스트가 됩니다.

그렇기 때문에 이를 expect.hasAssertions()를 추가하여 실행하면 다음과 같이 동작할 수 있습니다.

# hasAssertions()를 추가한 후 실행 결과
✗ fetchUserData handles invalid userId (5ms)
  
  Error: Expected at least one assertion to be called but received zero assertion calls.

이렇게 작성해주면 테스트가 올바르게 실패합니다. callback이 호출되지 않았다는 것을 명확히 알 수 있습니다.

3. 미친 1시간 반동안의 트러블 슈팅 - Fake Timers와 비동기 작업 간의 타이밍 이슈

제 과제상의 setupTest 파일은 다음과 같이 구성되어 있었습니다.

/* msw */
export const server = setupServer(...handlers);

beforeAll(() => {
  server.listen();
  vi.useFakeTimers();
});

beforeEach(() => {
  expect.hasAssertions();
  vi.setSystemTime(new Date('2025-10-15'));
});

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

afterAll(() => {
  vi.resetAllMocks();
  server.close();
  vi.useRealTimers();
});

그런데 과제를 하다보니 이상한 점을 발견합니다.

이걸 1시간 반동안 삽질을 했었는데요. 결론적으로는 https://github.com/testing-library/dom-testing-library/issues/1218 의 내용을 확인해보면 vi.useFakeTimers({ shouldAdvanceTime: true }); 한 줄만 추가해주면 되는 문제였습니다. 아니

이게 왜 그런지에 대해서는 일단 shouldAdvanceTime 옵션에 대해서 이해해야할 것 같습니다. https://github.com/vitest-dev/vitest/blob/main/docs/config/index.md#faketimersshouldadvancetime 를 보면 shouldAdvanceTime 옵션은

• @sinonjs/fake-timers에게 실제 시스템 시간 변화에 따라 자동으로 가짜 시간을 증가시키라고 지시합니다. (예: 실제 시간이 20ms 변할 때마다 가짜 시간도 20ms씩 증가) 라고 나와있는데요.

만약 shouldAdvanceTime가 false(기본값)인 경우에는 개발자가 명시적으로 vi.advanceTimersByTime()으로 수동 조작해야만 시간이 흐르게 됩니다. 때문에 비동기 라이브러리(제 과제에서의 findByText)와 호환성 문제가 발생할 수 있습니다.

반대로 shouldAdvanceTime가 true인 경우에는 위에서 언급된 것처럼 실제 시간이 흐르면 가짜 시간도 따라서 흐르기 때문에 비동기 라이브러리들과 잘 작동합니다.

다시 제 과제로 돌아가서

vi.useFakeTimers(); // shouldAdvanceTime: false (기본값)

await act(async () => {
  setup(<App />);
  vi.advanceTimersByTime(100); // ← 이때까지만 시간이 흐름
});

// 하지만 이 시점부터 시간이 완전히 멈춤
await screen.findByText('일정 로딩 완료!'); // ← 타임아웃!

shouldAdvanceTime가 false이니 명시적으로 시간을 돌려주지 않으면 시간이 흐르지 않고

// findByText 내부 구조 (단순화)
const findByText = (text) => {
  return new Promise((resolve, reject) => {
    const timeout = setTimeout(() => {
      reject(new Error('타임아웃!')); // ← 이 타이머가 실행되지 않음
    }, 1000);
    
    const poll = () => {
      const element = queryByText(text);
      if (element) {
        resolve(element);
      } else {
        setTimeout(poll, 50); // ← 이 타이머도 실행되지 않음
      }
    };
    poll();
  });
};

findByText가 내부적으로 타이머를 실행하는데, 이때 타이머가 멈춰있게 되어 타임아웃이 발생한...것이었습니다.

한시간 반이나 투자했으니 다음번엔 잘 기억하겠지 하고... 놓아주었습니다.

코드 품질

1. 불필요한 테스트

불필요한 테스트라고 여겨지는 부분에 대해서 상단에 주석을 달아두었습니다.

// getDaysInMonth에 대한 테스트 중
  // NOTE: 이 테스트는 불필요한 테스트라고 판단하였으나 최대한 현재 기능에 유사하게 구현하였습니다.
  // 테스트를 불필요하다고 판단한 이유는, getDaysInMonth 함수가 JavaScript 내장 기능 테스트에 지나치지 않는다고 판단했기 때문입니다.
  describe('잘못된 월 입력 처리', () => {
    test('13월 입력 시 이전 달(12월)의 일수인 31일을 반환한다', () => {
      expect(getDaysInMonth(2025, 13)).toBe(31);
    });

    test('0월 입력 시 이전 달(12월)의 일수인 31일을 반환한다', () => {
      expect(getDaysInMonth(2025, 0)).toBe(31);
    });

    test('-1월 입력 시 이전 달(11월)의 일수인 30일을 반환한다', () => {
      expect(getDaysInMonth(2025, -1)).toBe(30);
    });
  });
  
  // getTimeErrorMessage에 대한 테스트 중
    describe('입력값이 비어있는 경우', () => {
    test('시작 시간이 비어있을 때 에러 메시지를 반환하지 않는다', () => {
      const result = getTimeErrorMessage('', '15:00');
      expect(result.startTimeError).toBeNull();
      expect(result.endTimeError).toBeNull();
    });

    test('종료 시간이 비어있을 때 에러 메시지를 반환하지 않는다', () => {
      const result = getTimeErrorMessage('14:00', '');
      expect(result.startTimeError).toBeNull();
      expect(result.endTimeError).toBeNull();
    });

    // NOTE: 해당 테스트의 경우 상위의 두 테스트에서 검증이 가능하므로 불필요한 테스트로 생각됩니다.
    test('시작 시간과 종료 시간이 모두 비어있을 때 null을 반환한다', () => {
      const result = getTimeErrorMessage('', '');
      expect(result.startTimeError).toBeNull();
      expect(result.endTimeError).toBeNull();
    });
  });

제가 판단한 '불필요함'의 기준은 다음과 같습니다.

1. 구현체가 이미 브라우저 api로 충분히 파악 가능한 테스트다.
2. 하위 테스트에서 충분히 검증 가능한 테스트다.
3. 앞선 테스트에서 충분히 검증 되었다.

때문에 상기한 테스트들은 불필요하다고 판단했습니다.

2. 테스트를 작성하는 규칙

제가 이번에 테스트를 작성함에 있어서 스스로 규칙을 세워 테스트를 작성하였는데, 그 규칙은 다음과 같습니다.

1. Given When Then 방식으로 테스트를 구현할 것
2. describe가 구체적일것
3. 모든 구현을 커버하지 않아도 되고, 필요한 부분에 대해서 테스트를 작성할것
4. 무의미한테스트를 작성하지 않을것
5. 정상범위에 대해서는 테스트가 하나만 있고, 경계값이 있다면 그에 대한 테스트를 작성할것. 과도한 오버엔지니어링 금지 이전에는 테스트 커버리지가 높은 테스트 === 좋은 테스트라는 생각을 했었는데 이번에 테스트를 구현하면서는 어떤 것이 좋은 테스트일까를 더 생각하면서 구현했던 것 같습니다.(물론 아직도 쉽지 않습니다)

3. QnA때 들었던 힌트에 기반해서 테스트 구현하기

이부분은 사실 제가 갈피를 잘 잡은게 맞나 싶은 생각이 드는데요. 일단 제가 질문드렸던 질문 중

어떤 유닛 테스트의 event에 대해서 목데이터를 위치를 가깝게 둬야할까요? 아니면 멀리 두는게 좋을까요? 가까이 둔다는 의미는 테스트 파일 혹은 각 모듈 내부에 목데이터를 두는것, 멀리 둔다는 것은 따로 fixture를 두어 공통화된 데이터를 사용함을 생각했습니다. 가깝게 두면 의도가 분명하다는 이점이 있을 것 같은데요…그치만 추후에 인터페이스가 변경되면 모든 곳에서 변경해주어야 해서 관리하기가 어려울 수 있을거같습니다. 어떤게 더 나은 방법일까요?

라는 질문을 통해서, 일반적인 케이스들에 대해서는 관통하는 fixture를 두고 특수한 케이스에 대해서만 특수한 mockEvents를 두도록 변경했습니다.

가장 신경썼던 부분은 '테스트는 통과하지만 실제로는 통과하지 않은 시나리오를 찾아라'라는 진짜 수수께끼 같은 말씀이었는데요. 그를 계속 신경쓰면서 짜려고 했는데 어떤 부분에서 그 부분이 필요한 것인지 파악이 어려웠습니다.

그런데 setupTests.ts를 구현하다가 hasAsstions라는 함수에 대해서 알아보게 되었을때 '주로 비동기 테스트에서 assertion이 실제로 실행되었는지 확인하기 위해 사용한다' 라는 부분이 있었고 QnA에서도 코치님께서 설명한 부분이 데이터를 불러올때 비동기적으로 데이터를 불러오게 되는데 이에 대한 테스트를 작성해야한다? 라는 늬앙스가 있던 것으로 기억하는데요. 이번 테스트의 경우에 데이터를 로딩하고나서 '일정 로딩 완료!'라는 스낵바가 보여지게 되어 이를 통합테스트에서 검증하도록 했습니다.

  test('월별 뷰에 일정이 없으면, 일정이 표시되지 않아야 한다.', async () => {
    // Given: 해당 월에 일정이 없는 상태로 앱 시작
    vi.setSystemTime(new Date('2019-01-01'));
    setup(<App />);
    await screen.findByText('일정 로딩 완료!');

    // When: 월별 뷰를 확인 (기본값)
    // Then: 검색 결과가 없다는 메시지가 표시되어야 함
    const eventList = within(screen.getByTestId('event-list'));
    expect(eventList.getByText('검색 결과가 없습니다.')).toBeInTheDocument();
  });

일정이 없는 경우에는 일정이 말그대로 표시되지 않으므로 일정이 전체적으로 로딩되었는지에 대해 판단하기가 어려우므로 이를 '일정 로딩 완료!' 토스트가 발생하는지를 파악하도록 구현했고 그를 통해서 좀 더 안정적인 테스트 구현이 가능했다고 생각합니다.

갑자기 작성하면서 든 궁금증인데, 그렇다면 만약 로딩후에 저런 토스트 메시지가 없는 경우에는 어떻게 비동기적으로 데이터가 불러와졌음을 알 수 있을까요? 작성하면서 궁금해집니다.

학습 효과 분석

사실은요...

과제를 하다가 모달 관리하는 부분에 대해서 useOverlay라는 훅을 만들어볼까 생각했는데, 그렇게 되면 테스트코드를 짜야할거같다는 압박감이 들어 토스의 overlay-kit를...설치했습니다...ㅎㅎ 이부분을 Pr에다가 '저는 테스트를 전략적으로 라이브러리에 위임했습니다'하고 싶었는데 사실 좀 더 확실한 보증(?)이 있으면 좋겠다고 생각하던 찰나였습니다.

오프코치님이 개인적으로 질문드린 내용을 문의글에 올리셨는데

이 부분에 대한 검증은 html, react가 잘 구현이 되어있으면 잘 될거다! 정도로 볼 수도 있는 부분일수도

라고 하셔서 어? 이거 나한테 필요한 문장인데 싶어서 이때를 놓치면 안된다고 생각해 바로 질문을 드렸습니다.

원래 허락보다 용서가 빠르고, overlay-kit 을 써도 되냐 여쭤보면 직접 구현하고 테스트 작성하라는 말씀을 하실 것 같아서 ㅎㅎ 안여쭤보고 진행하려고 했는데 기회는 역시 찾아오더라고요. 일단 넹이라는 글자를 보자마자 '이때다' 싶었습니다. 다른 글자는 눈에 보이지도 않고 내가 라이브러리를 사용한 것에 대해서 허락정도가 아니라 타당한 이유를 만들어 주심에 너무 감사했습니다 ㅎㅎ 제가 문의글에 질문한 내용 중 가장 재밌던 질문이었다고 생각합니다. ㅎㅎ (암튼 전략적이잖아~)

암튼 비슷하게, 사실 실무적으로 테스트코드를 계속 해서 관리하는 조직이 아니라면 테스트 코드는 e2e가 아니더라도 값비싼 코드라고 생각이 드는데요. 이런 부분을 라이브러리에 위임해서 검증토록하는 방식이 유의미하다는 것을 알게되었다고 생각합니다.

또 이번에 준일님이 알려주신 https://www.npmjs.com/package/fast-check 요 라이브러리를 이번 과제에 써보고 싶었는데 그러지 못해서 좀 아쉬움이 남습니다. 이부분을 랜덤적으로 발생하는 숫자에 대한 검증용도로 사용할 수 있었을 것 같은데...아무튼 다음에 실무에 적용해 볼 수 있다면 써봄직한 수확이라고 생각합니다.

과제 피드백

오프코치님께서 숨겨놓으셨다는 이스터에그(?)들이 너무너무 궁금합니다...제가 의도를 제대로 파악하는게 맞는것인지..너무너무너무 궁금합니다... 이번주 발제때 알려주셨으면 좋겠어요 ... 🥹

리뷰 받고 싶은 내용

1. useEventForm이라는 애가 너무 책임이 거대한것 같아서 내부적으로 역할을 분리하게 되었습니다. 그중에 useTimeValidation이라는 훅을 만들었습니다. 이 훅은 내부적으로 getTimeErrorMessage를 쓰는데 해당 유틸은 이미 유닛테스트가 존재합니다. 일단 저는 이 getTimeErrorMessage에 대한 검증을 useTimeValidation에서 하는게 의미가 없다고 생각하는데요.

그렇다면 useTimeValidation에서 할수있는 테스트는 구현에 대한 부분만 보면 상태 업데이트, 인터페이스관련, 핸들러를 생성하는 부분에 대한 것 정도가 될거같은데 이런 부분에 대한 검증이 의미가 있는 것일까요?

정리하자면 유틸함수에 대한 테스트가 구현되어있고, 이를 단순히 이용해서 상태를 관리하는 훅이 있다고 하면 이 훅에 대한 테스트가 유의미하다고 생각하시나요? '오류 상태에서 정상적인 값으로 변경하면 오류가 초기화되어야 한다' 와 같이 상태 업데이트 정도는 검증할 수 있겠다는 생각이 드는데, 어디까지 검증을 해야하는지 좀 모호한 것 같습니다.

2. 단순히 presentation 컴포넌트로 뷰잉역할을 하는 컴포넌트가 있을때 props로 핸들러들이 넘어온다는 이유로 어떤 이벤트가 발생햇을때 이벤트 핸들러를 모킹해서 테스트 하는게 의미가 있을까요?

3. 데이터가 전부 비어져있는 상황인 경우에 로딩후에 '일정 로딩 완료!'와 같은 토스트 메시지가 없다면 어떻게 데이터가 불러와졌음을 알아 차릴 수 있을까요?