[우테코] 19편 : 오픈미션 13일차

| 서론

안녕하세요 팡일입니다!

오늘은 우아한테크코스 8기 프리코스의 오픈미션 13일차 포스팅입니다. 오늘은 진행한 점들에 대해서 기록하고 공유하려고 합니다!

| 오늘 한 일

1) 테스트

• vitest, playright 적용해보기

2) QA

• QA 아카이빙 노션 만들기

3) 리팩토링

• 추가할 기능에 대해서 더 고민해보기

| 어려웠던 점

1) 테스트 환경 설정의 높은 진입 장벽

: SvelteKit에 Vitest와 Playwright를 추가하는 과정은 단순히 라이브러리를 설치하는 수준이 아니었습니다. 특히 Vitest에서 Svelte 컴포넌트를 테스트하려 할 때 발생하던 lifecycle_function_unavailable 에러, 그리고 $lib 경로 별칭이 테스트 환경에서 인식되지 않는 문제 때문에 여러 번 막히곤 했습니다. 이를 해결하기 위해 vite.config.ts에서 alias가 테스트 환경에도 전달되도록 조정해야 했고, 또한 jsdom 환경에서 동작하지 않는 부분은 mocking으로 우회해야 하는 경우도 있었습니다.

이 과정에서 테스트 환경이 Node.js와 브라우저의 동작 방식이 완전히 다르다는 점을 몸으로 깨달았습니다.

SvelteKit의 런타임과 Vitest의 런타임이 어긋날 때마다 “왜 로컬에서는 되는데 테스트에서는 안 되지?”라는 고민을 계속 반복하게 되었습니다

2) E2E 테스트의 비동기성과 디버깅

: Playwright는 실제 브라우저를 기반으로 동작하는 만큼 모든 행위가 비동기적입니다. 특히 요소가 렌더링되는 타이밍과 Playwright가 셀렉터를 찾는 타이밍이 조금만 어긋나도 테스트가 실패하곤 했습니다. headless 환경에서 실패했을 때는 난이도가 더 올라갔습니다.

제 눈앞에서는 UI가 정상적으로 보이고 동작하는데, CI나 headless 모드에서는 요소를 찾지 못하거나 페이지 이동이 예상보다 느리게 처리되며 실패하는 경우가 많았습니다. 결국 Playwright의 debug 모드, trace viewer, 같은 기능을 하나씩 익히며 “브라우저가 실제로 어떤 순서로 움직이고 있는지”를 직접 확인하면서 디버깅해야 했습니다. 이 경험은 분명 시간 들여 학습해야 하는 새로운 영역이었습니다.

| 배운 점

1) 유닛 테스트가 주는 코드의 견고함

: formatDate 함수에 대한 테스트를 작성하면서 유닛 테스트의 진짜 의미를 제대로 느낄 수 있었습니다. 겉으로 보기에는 문제가 없어 보이던 코드가 경계값 테스트나 다양한 날짜 포맷을 넣어보는 순간 미묘한 오류들을 드러냈습니다. 테스트를 통과하도록 코드를 개선한 뒤에는

이 함수가 어떤 입력이 들어와도 안정적으로 동작하리라는 확신을 얻었습니다.

Vitest의 빠른 피드백 덕분에 수정 → 테스트 → 수정의 반복 과정도 무척 쾌적했습니다. “테스트는 귀찮은 절차가 아니라, 오히려 코드를 마음 편하게 만들어주는 장치구나”라는 감각을 처음으로 느꼈습니다.

2) 사용자 시나리오 기반의 통합 테스트 경험

: Playwright로 실제 사용자 시나리오를 코드로 옮겨보면서 E2E 테스트가 존재하는 이유를 명확하게 이해할 수 있었습니다. 회원가입, 로그인, 글 작성, 저장 이 과정들을 하나의 흐름으로 테스트했을 때 서비스 전체가 유기적으로 잘 연결되어 있다는 인상을 받았습니다.

단순히 “페이지가 뜬다” 수준을 넘어, 브라우저가 자동으로 움직이며 기능이 순서대로 정상 동작하는 모습을 확인했을 때 “이제 이 서비스는 배포해도 되겠다”라는 자신감을 얻을 수 있었습니다.

| 내일 목표

1) 기타

• 관리자 페이지

2) QA 진행

| 한 줄 회고

: "우테코에서 배운 테스트를 한 번 써보자,,!"