[WIL] 프론트엔드 테스트코드 - 8주차 과제

이번 8주차는 TDD를 진행해보는 시간이였다.

지난주차에 공부했던 프로젝트에 추가적으로 기능을 추가하는 미션이였는데, 그 미션을 TDD로 진행하는것이였다.

따라서 테스트를 작성하고, 테스트 코드를 작성, 그리고 기능을 작성, 검증 이 단계를 거치는 연습을 하게 되었다.

그럼 본격적으로 내가 배운점들을 요약해보겠다.

배운 점

• TDD 사이클 실습
  이번 과제는 Red → Green → Refactor 사이클을 처음부터 끝까지 경험할 수 있었다. 기능 요구사항이 명확했기 때문에 테스트를 먼저 작성하고 구현을 뒤따라가는 흐름이 비교적 자연스러웠다.
  테스트 코드가 실패하는 순간, 내가 무엇을 구현해야 하는지 방향이 명확해지는 걸 느꼈다. “기능 구현의 나침반” 같은 역할을 실제로 체감했다.
• 테스트 도구 활용 능력 향상
  • vitest-preview를 사용하면서 실패 시점의 UI를 눈으로 확인할 수 있었고, 덕분에 디버깅 시간을 크게 줄일 수 있었다.
  • testId 같은 속성을 전략적으로 추가해 테스트에서 UI 요소를 쉽게 식별하는 방법을 배웠다.
• AI와 TDD의 조합
  기능 구현을 대부분 AI에게 맡기고, 나는 테스트 설계와 보정에 집중했다. 이 과정에서 AI의 한계(구조적 이해 부족, MUI 특성 오판 등)를 보완하는 역할을 테스트 코드가 해준다는 걸 실감했다.
  → 결국 “AI에게 넘길 최소 단위 작업을 어떻게 정의할 것인가”가 생산성을 좌우한다는 점을 배웠다.

고민한 점

• 알림 토스트 중복 발생 (테스트 환경 vs 실제 환경)
  알림 검증 시 vi.advanceTimersByTime()을 사용했는데, 테스트에서는 토스트가 1번이 아닌 여러 번 발생했다.
  원인은 알림 체크가 setInterval(1000ms) 기반으로 이루어지고, 테스트에서 시간을 강제로 점프했을 때 이벤트가 여러 번 감지된 것으로 추정된다.
  실제 앱에서는 한 번만 발생하는데, 테스트 환경에서는 “밀린 이벤트”가 중복으로 발생한 것처럼 처리된 셈이다.
  → 억지로 -1000ms를 빼는 식으로 통과시켰지만, 이는 근본적인 해결은 아니라고 생각한다.
  앞으로는 “시간 이벤트를 시뮬레이션할 때 interval 기반 로직을 어떻게 안정적으로 테스트할지” 더 고민해봐야겠다.
• 극값 테스트의 필요성
  하루 종일 일정(00:00–23:59)이나 시작=종료시간 같은 케이스는 실제 사용자가 자주 쓰지는 않겠지만, 시스템 안정성을 위해 필요한 테스트라고 판단했다.
  다만 사용자 관점에서는 일정 충돌이나 잘못된 입력 처리 같은 케이스가 훨씬 중요하다.
  → “시스템 안정성 테스트 vs 사용자 중심 테스트” 사이의 우선순위를 어떻게 정할지가 앞으로도 계속 고민될 것 같다.

기술적 성장

• 단순히 “테스트를 작성할 수 있다”에서 한 단계 나아가, 테스트 전략을 고민하고 팀과 합의할 수 있었다.
  • 우리 팀은 “테스트 트로피에서 E2E는 제외하고, 통합 테스트를 중심으로 간다”는 전략을 세웠다.
  • 이유: 요구사항이 계속 바뀌는 환경에서 E2E는 유지보수 비용 대비 효율성이 떨어지고, 통합 테스트만으로도 사용자 여정을 충분히 커버할 수 있기 때문이다.
• 이는 단순 기술이 아니라 실제 현업에서 테스트 리소스를 어디에 집중해야 하는가라는 전략적 관점을 배우는 경험이었다.

아쉬운 점 & 다음 목표

• 테스트 코드가 실제 동작과 불일치할 때(알림 중복 이슈처럼) 원인을 깊게 파악하기 어려웠다. 라이브러리 레벨의 동작이나 타이머 메커니즘을 더 공부해야 한다고 느꼈다.
• 앞으로는 시간 관련 로직 테스트를 별도의 유틸 함수로 분리하고, 단위 테스트와 통합 테스트를 다른 접근법으로 나누는 방식을 시도해보고 싶다.
• 또한 이번에 통합 테스트에 집중했지만, 나중에는 서비스가 복잡해졌을 때 E2E를 어디서 도입해야 할지 미리 감을 잡아두고 싶다.