일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 개발자북클럽
- 프론트앤드
- 항해플러스프론트앤드
- 사이드프로젝트
- 타로프로젝트
- 타로엠비티아이
- 항해 플러스 프론트앤드
- 항해플러스 프론트엔드
- 개발회고
- Supabase
- 항해플러스 프론트앤드
- 항해플러스
- 프론트엔드사이드프로젝트
- corser챌린지
- 타로웹서비스
- 웹개발
- tailwindcss
- 노개북
- jqueryplugin
- whispersofthestars
- 프론트앤드개발
- plugin
- 항해99
- 노마드코더
- niceselect사용법
- select플러그인
- NextJs
- 프론트엔드
- book_club
- GeminiAPI 405
- Today
- Total
ㅇㅅㅇ
항해플러스 프론트엔드 6기 8주차 회고 본문
여덟 번째 도전기 - TDD와 함께한 성장의 시간
7주차에서 테스트 코드의 기본을 익혔다면, 이번 주차는 실제로 TDD 사이클을 따라가며 새로운 기능을 구현하는 실전 단계였습니다. TDD의 이상과 현실을 동시에 경험했습니다.
또한, 이번 주차에는 개인적으로 타로를 주제로 한 발표(8주차 스피커 활동)도 병행했습니다. 테스트와 리팩토링 과제를 진행하면서 동시에 발표를 준비해야 했지만, 좋아하는 주제로 사람들과 소통할 수 있었던 의미 있는 시간이었습니다.
과제를 통해 배운 것들
TDD 프로세스 - Red, Green, Refactor
이번 과제에서 처음으로 제대로 TDD 사이클을 의식적으로 따라가봤습니다.
🔴 Red - 실패하는 테스트 작성
describe('반복 일정 생성', () => {
it('매일 반복 일정을 생성할 수 있다', () => {
const result = generateRecurringEvents({
type: 'daily',
startDate: '2024-01-01',
endDate: '2024-01-05'
});
expect(result).toHaveLength(5);
});
});
처음엔 당연히 함수가 없으니 실패합니다. 이 단계에서는 "어떤 기능이 필요한가"를 명확히 정의하는 것이 핵심이었습니다.
🟢 Green - 테스트를 통과시키는 최소한의 코드
복잡한 로직을 고민하기보다는 테스트만 통과시키는 것에 집중했습니다. 처음엔 정말 단순하게 구현했습니다.
♻️ Refactor - 리팩토링
테스트가 통과하면 코드를 정리하고 개선했습니다. 이 과정에서 테스트가 있다는 것이 큰 안심이 되었습니다. 코드를 바꿔도 테스트가 깨지지 않으면 안전하다는 확신을 가질 수 있었습니다.
테스트 코드 작성 경험
- 단위 테스트 : 순수 함수의 로직을 검증하면서 "이 함수가 정확히 무엇을 하는가?"를 명확히 정의하게 되었습니다. 특히 엣지 케이스를 테스트하다 보니 내가 놓치고 있던 예외 상황들을 발견할 수 있었습니다.
- 통합 테스트 : 컴포넌트들이 서로 어떻게 연결되어 있는지, 상태가 어떻게 전파되는지 이해하게 되었습니다. UI 반응을 테스트하면서 사용자 관점에서 생각하는 습관이 생겼습니다.
- E2E 테스트 : 실제 사용자가 앱을 사용하는 전체 플로우를 검증하면서 "이 기능이 정말 사용자에게 도움이 될까?"라는 질문을 던지게 되었습니다.
TDD는 생각보다 어렵다
책이나 글에서 본 TDD는 매우 이상적이었습니다. 하지만 실제로 해보니 다음과 같은 어려움이 있었습니다.
- 무엇을 먼저 테스트해야 할지 막막했습니다 : 큰 기능을 작은 단위로 쪼개는 것이 생각보다 어려웠습니다. "반복 일정 생성"이라는 큰 기능을 어떤 단위로 나눠야 할까? 날짜 계산? 이벤트 객체 생성? API 호출? 처음엔 너무 큰 단위로 테스트를 작성해서 실패했습니다.
- 테스트를 작성하다가 구현하고 싶은 충동 : Red 단계에서 실패하는 테스트만 작성하고 멈추는 게 어색했습니다. 자꾸 "이 부분은 이렇게 구현하면 되겠네"라는 생각이 들면서 구현 코드를 먼저 작성하고 싶어졌습니다.
- 리팩토링 타이밍 판단이 애매했습니다 : 언제 리팩토링을 해야 할지, 얼마나 해야 할지 감이 잘 안 잡혔습니다. "이 정도면 충분한가?" vs "더 개선할 수 있지 않나?" 사이에서 고민이 많았습니다.
팀 논의의 중요성
월요일 팀 미팅이 정말 도움이 되었습니다:
- 테스트의 정의와 범위에 대한 공통 이해: 유닛, 통합, E2E 테스트가 각각 무엇을 검증하고 어떤 장단점이 있는지 서로의 관점을 공유했습니다.
- 테스트 전략에 대한 합의: 어떤 부분을 어떤 방식으로 테스트할 것인지에 대해 다양한 의견이 오갔습니다. 특히, 현실적인 제약 속에서 어떤 테스트에 우선순위를 둘 것인지, 그리고 E2E 테스트의 역할(QA의 역할 포함)에 대해서도 논의했습니다.
- 서로 다른 관점 공유: 같은 기능이라도 테스트 접근 방식이 다를 수 있다는 것을 배우며, 팀원들의 다양한 경험과 지식을 통해 시야를 넓힐 수 있었습니다.
특히 테스트 구분이 생각보다 명확하지 않다는 것을 알게 되었습니다. 예를 들어, 훅을 테스트하는 것은 단위 테스트일까 통합 테스트일까? 답은 "상황에 따라 다르다"였습니다.
프론트엔드에서 TDD의 한계
과제를 하면서 프론트엔드에서 TDD가 어려운 이유를 몸소 느꼈습니다:
- UI 변경이 잦다 : 테스트를 작성해놓으면 UI가 바뀔 때마다 테스트도 수정해야 합니다. 버튼의 텍스트가 바뀌거나 레이아웃이 변경되면 E2E 테스트가 깨집니다.
- 사용자 인터랙션 테스트가 복잡하다 : 클릭, 드래그, 입력 등 다양한 인터랙션을 테스트로 표현하기 어렵습니다. 특히 드롭다운이나 모달 같은 복잡한 UI 요소는 더욱 까다롭습니다.
- 비동기 처리 : API 호출, 타이머 등 비동기 로직이 많아 테스트가 복잡해집니다. 언제 데이터가 로드될지, 언제 상태가 업데이트될지 예측하기 어려웠습니다.
그래서 순수 함수로 분리할 수 있는 로직(날짜 계산, 데이터 변환 등)은 TDD로 접근하고, UI 로직은 나중에 통합 테스트로 검증하는 것이 효과적이었습니다.
테스트 작성의 실제 가치
이전에는 "테스트는 버그를 찾는 도구"라고만 생각했습니다. 하지만 이번 과제를 통해 테스트 코드가 다음과 같은 이점이 있다는 것을 알게 되었습니다.
설계 개선
테스트하기 쉬운 코드는 좋은 코드입니다. 테스트를 작성하다 보니 자연스럽게:
- 함수를 작게 만들게 되었습니다
- 의존성을 줄이게 되었습니다
- 순수 함수를 선호하게 되었습니다
문서화
테스트 코드가 기능 명세서 역할을 했습니다. 테스트를 보면 이 함수가 어떤 입력을 받고 어떤 출력을 내는지 바로 알 수 있습니다.
스피커 경험 – 타로를 개발로 풀어내다-
이번 주차에는 스피커로 발표할 기회를 가졌습니다. 제가 예전부터 관심을 두고 있던 타로를 주제로, 타로란 무엇인지,점사가 진행되는 순서, 그리고 그 관심이 어떻게 사이드 프로젝트로 발전하게 되었는지를 이야기했습니다.
항해를 진행하면서 간간히 함께 수강 중인 분들께 타로 리딩을 봐드리곤 했는데, 그래서인지 다들 조금은 궁금해하셨던 것 같습니다. 그때의 상담 경험이 발표를 준비할 때 큰 도움이 되었고, 내용 중 자주하는 질문 등 발표 내용의 일부 구성도 그 경험을 바탕으로 하게 되었습니다.
당시에는 테스트 코드 과제를 병행하던 시기라 준비 과정이 쉽지는 않았지만, 좋아하는 주제로 발표를 준비하면서 오히려 마음이 정리되는 시간을 보냈습니다. 타로를 공부하고, 사람들과 나눈 대화를 개발로 풀어내며 “내가 좋아하는 것을 코드로 표현할 수도 있구나” 하는 확신을 얻게 되었습니다. 이 경험은 앞으로 어떤 프로젝트를 하든 제 관심과 이야기를 담아낼 수 있는 용기를 주는 계기가 되었습니다.
KPT 회고
Keep (계속 유지하고 싶은 점)
- TDD 사이클을 의식적으로 따라가려고 노력
- 팀과 함께 테스트 전략을 논의하며 서로 다른 관점 공유
- 순수 함수로 분리할 수 있는 로직에 집중
- 테스트 코드를 통해 설계 개선 시도
Problem (개선이 필요한 문제점)
- 테스트 시나리오 작성의 어려움 - '이 테스트가 정말 의미가 있을까?'라는 의문
- Material-UI Select 컴포넌트와의 상호작용 테스트 복잡성
- E2E 테스트에서 요소가 가려지는 문제 해결에 시간 소요
Try (앞으로 시도해 볼 점)
- 실제 프로젝트에서 TDD 패턴을 더 체계적으로 적용
- React Testing Library의 비동기 유틸리티 더 깊이 학습
- E2E 테스트 작성 방법 완전히 익히기
- AI를 도구로 활용하면서도 토론, 조사, 고민 과정 병행
- 항해 종료 후 학습한 내용을 정리하고 개인 프로젝트에 적용
추천인 코드
제 후기를 보고 프로그램에 관심이 생기셨다면, 감사한 마음으로 수강료 할인을 받을 수 있는 추천인 코드를 드립니다.
수강 신청 시 추천인 코드 WlHJDO 입력하면 20만 원 할인이 적용되며, 자세한 커리큘럼과 일정은 아래 링크에서 확인하실 수 있습니다.
추천인 코드 : WlHJDO
https://hanghae99.spartacodingclub.kr/plus/fe
항해 플러스 | 도전을 넘어 개발자 커리어 도약으로
빅테크 시니어 코치진이 사수가 되어 드립니다. 시니어 개발자의 멘토링, 실무 포트폴리오, 동료 개발자들과의 인사이트 나눔까지.
hanghae99.spartaclub.kr
'항해99 플러스 프론트앤드 > 10주 과정' 카테고리의 다른 글
항해플러스 프론트엔드 6기 7주차 회고 (0) | 2025.10.09 |
---|---|
항해플러스 프론트엔드 6기 6주차 회고 (0) | 2025.10.08 |
항해플러스 프론트엔드 6기 5주차 회고 (0) | 2025.09.23 |
[WIL] 항해플러스 프론트엔드 6기 4주차 회고 (7) | 2025.08.04 |
[WIL] 항해플러스 프론트엔드 6기 3주차 회고 (13) | 2025.07.28 |