HARD

PR 체크포인트 및 구현 내용

7주차 과제 체크포인트

기본과제

• 총 11개의 파일, 115개의 단위 테스트를 작성하고 모두 통과

질문 답변

Q1. handlersUtils에 남긴 질문에 답변해주세요.

이벤트는 생성, 수정되면 fetch를 다시 해 상태를 업데이트합니다. 테스트가 병렬로 돌아도 안정적이게 동작할 수 있는 방법은?

처음에는 그냥 handlers.ts 안의 전역 events 배열을 각 테스트마다 초기화하면 되겠다고 생각했습니다. 그런데 실행해보니 한 테스트에서 추가한 이벤트가 다른 테스트에 나타나고, 삭제 테스트를 돌렸더니 엉뚱한 테스트가 깨지는 문제가 발생했습니다.

이 문제를 해결하기 위해 EventTestStore 클래스를 만들고, 각 테스트마다 독립적인 저장소를 생성하도록 바꿨습니다. Map 자료구조로 CRUD를 구현하고, setupMockEvents()에서 매번 새로운 인스턴스를 생성하게 하니 병렬 실행에서도 안정적으로 동작했습니다.

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

여러 시행착오 끝에 다음과 같은 방법을 적용했습니다.

1. ID 충돌 방지: 단순 숫자 ID는 충돌이 잦아 crypto.randomUUID()와 Date.now()를 조합해 사용
2. MSW 핸들러 격리: 각 테스트에서 server.use(...setupMockEvents([]))로 초기 데이터 지정
3. 타이머 격리: 알림 테스트에서 시간 문제로 고생했는데, 결국 각 테스트를 vi.useFakeTimers() / vi.useRealTimers()로 감싸 해결

심화 과제

• App 컴포넌트를 적절히 분리 (컴포넌트, 훅, 유틸 함수)
• 분리된 모듈들에 대해 5개 이상 테스트 작성

---

주요 구현 내용

1. 테스트 안정성 개선

처음엔 하나씩 실행할 때는 통과하지만 전체를 돌리면 절반 이상이 깨졌습니다. 원인이 전역 배열이라는 걸 알아내기까지 시간이 꽤 걸렸습니다. EventTestStore를 도입한 뒤에도 작은 문제들이 이어졌지만, 결국 핵심은 "각 테스트가 완전히 독립된 환경에서 돌아야 한다"는 점이었습니다.

2. 통합 테스트 개선

사용자 시나리오대로 테스트를 짜는 게 생각보다 쉽지 않았습니다. 예를 들어 "일정 추가"만 해도 입력 → 저장 버튼 클릭 → 서버 요청 → 목록 업데이트까지 단계가 많고, 비동기 처리 때문에 waitFor, findBy를 자주 쓸 수밖에 없었습니다.

3. 유틸리티 함수 테스트 강화

순수 함수라 작성은 비교적 수월했지만, 날짜 관련 엣지 케이스(윤년, 월말 등)를 고려하는 과정이 까다로웠습니다.

---

과제 셀프회고

기술적 성장

프론트엔드와 백엔드에서의 테스팅 관점 차이

백엔드에서는 도메인 객체와 비즈니스 로직이 중심입니다.

• 함수 단위, 로직 단위에서 발생할 수 있는 사이드 이펙트 최소화에 집중했습니다.
• 유닛 테스트는 입력과 출력만 명확히 정의하면 되었고, 리팩터링 시 안정망 역할을 충실히 했습니다.
• 예를 들어, OAS로 API 스펙을 정의한 뒤, 입력/출력 값이 바뀌지 않는 한 테스트 코드도 안정적으로 유지되었습니다.

반면 프론트엔드에서는 훨씬 다른 성격의 어려움이 있었습니다.

• 클릭 → 상태 변화 → 서버 요청 → UI 업데이트라는 사용자 플로우 전체를 검증해야 했습니다.
• 특히 비동기 통신, DOM 업데이트 타이밍, 타이머와 같은 UI 특수성이 결합되면서, 단순히 함수 리턴값만 보는 백엔드 테스트보다 훨씬 복잡했습니다.
• 따라서 단순 유닛 테스트보다는 통합 테스트 시나리오 설계와 테스트 격리가 핵심이 되었고, 이번 과제에서는 EventTestStore 같은 별도의 구조를 설계해야만 병렬 실행 환경에서도 안정성을 확보할 수 있었습니다.

즉,

• 백엔드는 로직 검증이 주가 되었다면,
• 프론트엔드는 사용자 경험(UX) 시나리오 보장이 테스트의 본질적 목표였습니다.

과거 블로그 경험과의 연결

과거에 블로그 포스팅에서,

“유닛 테스트가 있으면 리팩터링이 두렵지 않았다”

라는 경험을 쓴 적이 있습니다. 그때는 리팩터링을 하며 느낀 점이었는데, 이번 과제를 하며 똑같은 깨달음을 다시 했습니다.

프론트엔드에서도 테스트가 있으니 컴포넌트를 분리하고, 훅으로 로직을 추출하고, 구조를 과감히 바꾸는 과정이 두렵지 않았습니다. 이번 경험은 “테스트는 백엔드/프론트엔드를 가리지 않고 개발자의 자신감을 높여주는 가장 강력한 도구”라는 걸 다시 한번 확인한 시간이었습니다.

타이머 관련 테스트 이슈

fake timer를 쓰면서 시간이 지나도 알림이 뜨지 않는 문제가 있었습니다. 원인은 fake timer는 시간을 가짜로 진행시키는 반면, React의 상태 업데이트나 waitFor는 실제 시간을 참조한다는 점이었습니다.

(하도 안되서 영서님께 이거 뭐냐? 여쭤보니 대뜸 아래의 링크를 보내주더라고요. 항상 고마운 영서님 ㅎㅎ)

dom-testing-library #1218

• fake timer는 가짜로 시간을 진행시키는데
• React의 상태 업데이트나 waitFor는 실제 시간을 쓰더라구요
• 그래서 둘이 싱크가 안 맞아서 테스트가 제대로 안 돌아감

해결 방법은 다음과 같았습니다.

vi.useFakeTimers({ shouldAdvanceTime: true });
await act(async () => {
  vi.advanceTimersByTime(1000);
});

shouldAdvanceTime 옵션을 알게 된 후에서야 문제를 해결할 수 있었습니다. 문서에서 찾기 힘들어 애를 많이 먹었던 부분입니다.

코드 품질

• 만족스러운 부분: EventTestStore 설계. 단순히 Map만으로도 복잡한 문제를 깔끔하게 정리할 수 있었습니다.
• 아쉬운 부분: 통합 테스트가 길어져 가독성이 떨어진 점. 공통 동작을 헬퍼 함수로 추출하는 등 개선 여지가 있습니다.

학습 효과

테스트가 리팩터링 과정에서 얼마나 큰 힘이 되는지 체감했습니다. 구조를 과감하게 바꿀 수 있었던 건, 테스트가 기능이 유지되고 있음을 보장해줬기 때문입니다.

아직은 시각적 테스트나 스냅샷 테스트 활용 시점이 애매하게 느껴집니다. 이 부분은 더 학습이 필요할 것 같습니다.

과제 피드백

• 좋았던 점: 실무에 가까운 앱을 대상으로 테스트를 연습할 수 있었고, MSW도 제대로 활용해볼 기회였습니다.
• 아쉬운 점: 병렬 실행 환경에서 테스트를 안정적으로 돌리는 방법에 대한 가이드가 조금만 더 있었으면 시행착오를 줄일 수 있었을 것 같습니다.

---

리뷰 받고 싶은 내용

1. EventTestStore 패턴 Map 기반으로 구현했는데, 이 방식이 다른 프로젝트에서도 일반적으로 사용하는 접근인지 궁금합니다. factory 패턴이나 builder 패턴으로 확장하는 게 더 적절할까요?

2. 통합 테스트 범위 medium.integration.spec.tsx 같은 경우, "일정 추가" 테스트에서 폼 입력 → 저장 → 목록 확인까지 전 과정을 한 테스트로 두었는데요. 이렇게 긴 시나리오를 그대로 두는 게 맞는지, 아니면 쪼개는 게 더 바람직한지 고민입니다. 만약 쪼갠다면 어떤 기준이 적절할까요?

3. 테스트 데이터 관리 createTestEvent()를 통해 기본값을 세팅하고 필요한 부분만 오버라이드하는 방식을 썼습니다. 그런데 경우에 따라선 오히려 혼란스럽기도 했습니다. 매번 완전한 데이터를 새로 만드는 방식과 비교했을 때 어떤 접근이 더 유지보수에 유리할까요?