[4팀 오하늘] Chapter 3-2. 프론트엔드 테스트 코드

[eveneul]

8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

저라는 팀장의 권력욕 주도 하에 4, 7 페어팀의 피그잼을 만들어 그 안에서 팀원들끼리 유닛 테스트, 통합 테스트, e2e 테스트 관련 개인의 생각과 선호도 조사(?)를 진행했다.

테오하늘의 멘토링

7팀 정건휘:

• 유닛 테스트: 복합적이지 않은 작은 단위의 코드를 테스트하는 것. 실질적인 동작의 기능 명세를 확인할 수 있는 것.
• 통합 테스트: 유닛 테스트로 검증된 테스트들을 포괄하는 테스트, 확신을 가진 상태에서 더 큰 범위의 로직 테스트를 진행하는 것.
• E2E 테스트: 사용자의 행동 패턴을 바탕으로 처음부터 끝까지의 과정을 테스트하는 것. 물론 큰 기능 단위로 쪼개어 각 E2E 테스트를 분류하면 관리가 쉬워질 것 같음.

4팀 김수민:

• 유닛 테스트: 작은 로직을 테스트하기 위한 테스트.
• 통합 테스트: 무엇인지 아직 감이 잘 오지 않는다. 유닛 테스트와 e2e 테스트의 중간이라고 들은 것 같고, 기능 단위로 테스트하는 것인지 의문.
• e2e 테스트: End to End 테스트. 유저 플로우의 시작과 끝을 모두 검증하는 테스트.
• 개인 생각: 리소스가 뒷받침된다면 e2e 테스트를 하는 게 당연히 좋겠지만, 커뮤니케이션이나 시간적인 비용이 많이 들 듯 하다. UX가 중요한 상황이라면 통합 테스트까지 고려해 볼 수 있지 않을까.

여기에서 궁금한 점이 생겼다. UX가 유독 중요한 프로젝트가 있을까? 그렇게 치면 모든 서비스에 UX가 중요할 텐데? e2e까지 넘어가야 할 UX 테스트가 있을까? 라고 생각이 들었다.
7팀 학습메이트 황태영: 예를 들어 모달창 같은 경우 딤 영역을 클릭했을 때 닫히지 않으면 당황스러운데, 그런 것들을 말하는 것이 아닐까?
4팀 김수민: 롤백 하지 못하는 프로젝트들에 대해서는 UX가 많이 중요하다고 생각이 됨. B2C 서비스는 그렇다 쳐도, B2B는 고객들이 사용료를 내고 우리의 서비스를 사용하는 것이기에 쉽게 롤백을 하지 못하니, 그럴 경우에는 UX가 많이 중요하다고 생각하고, 그럴 때는 통합 테스트나 e2e 테스트가 필요할 것 같다.

4팀 김지혜:

• 유닛 테스트: 작은 함수나 컴포넌트 단위의 로직을 검증하는 테스트. 빠르고 세밀하다. 코드 레벨에서 버그를 빠르게 잡을 수 있다. 하지만 시스템 전체의 흐름은 보장하지 않는다.
• 통합 테스트: 여러 모듈이나 서비스가 서로 연결되어 동작할 때 올바르게 작동하는지 검증하는 테스트. 단위 테스트로 잡지 못하는 연결 오류를 발견할 수 있다.
• E2E 테스트: 사용자의 실제 사용 흐름(브라우저 클릭, 입력 등)을 시뮬레이션하는 테스트. 실제 사용자 관점에서 “이 앱이 문제없이 동작하는가”를 확인하는 테스트이다.
• 개인 생각: 비용이 적고 소소한 유닛은 필요한 만큰 필수로 하고 e2e는 비용이 많이 드니까 최소한만 일단?

7팀 학습메이트 황태영:

• Unit 테스트:
  필수 대상: 날짜/요금 계산, 정책 판별 등 작은 단위지만 오류 발생 시 치명적인 로직.
  선택 대상: 중요도가 낮은 로직은 필요 시 선택적으로 적용.
 → “절대 깨지면 안 되는 핵심 로직”에 집중하는 전략.
• Integration 테스트:
  대상: 여러 로직이 결합된 Hook 중심.
  특징: 유저 동작 기반 테스트도 가능하지만, jsdom 환경 특성상 한계가 있어 효율이 낮다고 판단.
  결론: 할 수는 있지만, 실질적으로는 E2E가 더 낫다고 생각.
• E2E 테스트:
  대상: 실제 유저 동작 전체 시나리오(검색→선택→결제 등).
  장점: 크로미움 기반 브라우저 환경으로 실제 사용자 경험과 가장 유사.
  필요성: 가능하다면 반드시 하는 것이 가장 바람직하다고 평가.
• 개인 생각:
  비즈니스 로직처럼 중요한 부분부터 적용.
  적용 순서: Unit → E2E → Integration
 (중요 로직은 Unit으로, 실제 사용 시나리오는 E2E로, 나머지 결합은 Integration으로).

4팀 오하늘:

• 유닛 테스트: 가장 작은 함수 (순수함수)나 컴포넌트, 훅 등을 테스트함 → 빠르고 버그를 초기에 발견할 수 있지만 너무 세분화하거나 프로젝트 볼륨이 커지면 커질수록 테스트 코드가 많아지고 길어질 것 같음.
• 통합 테스트: 유닛에서 검증한 함수나 컴포넌트, 모듈 등을 합쳐서 상호작용이 잘되는지에 대한 테스트. 실제 사용자의 UX나 시나리오처럼 테스트할 수 있지만 초기 세팅이 오래 걸릴 것 같음. 기획자가 와서 이건요? 저건요? 훈수질 둘 것 같음.
• E2E 테스트: 사용자가 실제 브라우저(앱)에서 하는 플로우를 그대로 테스트. 프론트뿐만 아니라 백앤드까지 포함된 실제 환경 전체를 테스트 단점은 느리다.
• 개인 생각: 솔직히 다 필요할 것 같다고 생각하지만 현실적으로 생각하기에는 태영 님이 말씀하신 것처럼 유닛 → e2e → 통합으로 가는 게 좋을 것 같다.

7팀 양창훈:

• 유닛 테스트: 순수 함수로만 이루어진 모듈들의 테스트.
• 통합 테스트: 렌더링된 컴포넌트나 함수들을 실제와 가까운 환경으로 만들어 결과값이 정상적으로 작동하는지 테스트.
• e2e 테스트: 실제 네트워크다 DB 등 전체 흐름을 구동하여 하는 테스트.

4팀 이유진:

• 유닛 테스트: 개별 순수 함수, 컴포넌트 같은 작은 단위가 올바르게 동작하는지 검증하는 테스트 → 가장 빠르고 저비용으로 버그를 걸러낼 수 있음
• 통합 테스트: 여러 모듈이나 컴포넌트를 연결해 실제 상호작용이 기대대로 이루어지는지 검증하는 테스트 → 실제 모듈 간 상호작용을 보장하고 비용이 e2e 만큼 많이 들지 않아서 중요하다고 생각.
• E2E 테스트: 사용자가 브라우저에서 경험하는 흐름을 실제 시나리오 기반으로 검증하는 테스트 → 가장 현실과 가까운 테스트이지만 비용이 커서 쉽지 않을 수도 있다고 생각.

7팀 강병준:

• 유닛 테스트: 최소 단위의 모듈(함수, 공통 컴포넌트 등)을 검증하기 위한 테스트로서 개별 모듈이 정상적으로 동작하는지를 테스트하기 위한 것
  “모듈을 신뢰할 수 있는가?”

• 통합 테스트: 여러 개의 모듈(컴포넌트, 서비스, 훅 등)이 서로 상호작용하는 과정을 검증하기 위한 테스트. 단일 함수가 올바르게 동작하는지 보는 게 아니라, 이벤트 → 여러 모듈 호출 → 결과라는 흐름이 끊김 없이 잘 이어지는지를 확인하는 것
  “모듈들이 서로 잘 맞물리는가?”

• E2E 테스트: 사용자 관점에서 서비스의 전체 흐름(워크플로우)을 끝까지 검증하는 테스트
  “사용자가 실제로 이 제품을 써서 원하는 가치를 얻을 수 있는가?”

개인 생각: 단위 테스트도 함수의 안정성이나 품질을 보장하기 위한 하나의 수단으로서 굉장히 중요한 건 사실이지만 순수 함수로 구성된다면 부작용이 발생하는 상황이 적을텐데이번 과제에서 필요할까? 통합 테스트에 조금 더 집중하고 비즈니스적 가치를 전달할 수 있는 즉 메인 기능(12개)에 대해서는 E2E를 작성해보면 좋지 않을까?

4팀 김소희:

• 유닛 테스트: 최소 단위의 모듈을 검증하기 위한 테스트.

• 통합 테스트: 여러 모듈이 상호작용 하는 과정을 검증하기 위한 테스트.

• e2e 테스트: 사용자 관점에서 서비스 전체 흐름을 검증하는 테스트.
  (사실 소희 님은 병준 님이 쓴 거 요약했다.)

• 개인 생각: 나에게 테스트 코드란 쿠션이다... 넘어져도 다치지 않게 해 주는... ^^ 폭신폭신한 친구랄까.

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

테스트 코드 챕터 첫 번째 주차일 때, 테오 멘토링에서 테스트 코드를 어디에서부터 어디까지 감안을 해야 할지 모르겠다는 질문을 남긴 적이 있다. 테오는 Given → When → Then 패턴에 대해 알려 줬고, 그 패턴을 이번 과제에 도입하자고 또 팀장 권한으로 주장했다. 고맙스럽게도 팀원들이 내 의견에 동의해 주었고, 동일한 피그잼에 그 패턴으로 기본 과제 요구사항들을 정리했다.

(같이 도와준 팀원들 고마우이..)

과제 관련 노션 안에 있는 요구 사항들을 Given → When → Then 패턴으로 정리하자 테스트 코드에 대한 description을 쓰기도 쉬웠고, 특히 건휘 님이 말씀하신 것처럼 결국 테스트 코드는 Then에 적은 것들을 코드로 작성하면 되니 테스트 코드 작성이 (다른 분들은 어떨지 모르겠지만, 우선 나는) 수월했다.

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

repetition.integration.spec

팀원들과 같이 정리한 내용을 토대로 작성한 테스트 코드다. expandRecurringEvent 함수로 반복 유형에 따른 일정 생성 테스트와 윤년 2월 29일에 일정 생성 시 2025-03-01에 일정이 생기지 않고 다음의 윤년에 일정이 생기는지 등을 판별하는 테스트 코드를 작성했다.

---

과제 셀프회고

기술적 성장

테오가 알려 준 Given → When → Then 패턴을 회사 실무에서 적용해 보려고 했는데, 매! 일! 매! 일! 바뀌는 요건들과 당최 알 수 없는 요구사항들을 정리하기 쉽지 않아서 마음속으로 묻어두어야 하나 했지만.. 이번 과제로 인해 처음으로 패턴을 도입하게 되어 기분이 좋았다. 생각보다 많이 노가다 같지만, 기획서가 무엇을 요구하고 어떻게 해결해 나가야 하는지에 대한 힌트 같은 패턴이라고 생각되어 정말 많이 좋았다. 팀을 사랑하는 마음도.. 다들 고생했어양..

코드 품질

말로만 듣던 TDD에 대해 조금은? 깊게 고찰해 볼 수 있는 시간이었다. 특히 과제를 진행하면서 우리 팀에서는 소희 님, 병준 님이 제일 먼저 과제를 완수해서 커밋 내역을 훑어 봤는데, 나와 많이 다르게 구현을 해 놓았다. 나는 mockEvent를 테스트 하나하나에 다 작성해 놓았는데, 사실 그럴 필요가 없었던 것 같기도 하고.. 사실 코드 한 줄 한 줄이 다 리팩토링 대상 같다.

학습 효과 분석

가장 큰 배움은 E2E 테스트 코드의 작성이다. Cypress를 처음 접해 봤는데, 병준 님이 말씀하신 것처럼 Cypress에서 사용하는 문법들이 익숙하지 않아서 초반에는 애를 많이 먹었다.

사실 결론적으로 말하자면, Cypress로 작성한 e2e 테스트 코드들을 다 지웠다. 시간이 부족하기도 했고, 내 마음대로 진행이 안 되어서... 인데, 로컬 서버에서는 너무나도 잘 작동하는 것이 Cypress에서는 되지 않았다. 아직 이 부분에 대해서는 배움이 필요하다.

과제 피드백

그래도 깔짝거리면서 작성한 e2e 테스트 코드에서 DOM을 추적할 때 dataset으로 data-test...를 기입했다. 그런데 이게 과연 옳은 것인지 모르겠다. 어차피 다 지워야 되는 데이터셋 아닌가.. 그렇다면 className이나 id로 찾을 텐데, 요즈음에는 tailwind CSS를 자주 사용하니까..... 라고 생각했다.

리뷰 받고 싶은 내용

사실 TDD의 강점을 잘 모르겠습니다. 제가 TDD를 너무 많이 기대했던 걸까요. ㅎㅎ 코치님이 생각하시는 TDD의 강점? 그리고 취향은 어떤지 궁금합니다.