Vitest 는 빠른 inner loop. Playwright 는 느리지만 정직한 outer loop.
테스트는 ship 직전에 찍는 체크박스가 아냐. 코드를 의심하지 않고 믿게 되는 순간이지.
9 tracks · 32 lessons · ~16h · difficulty: intermediate-to-advanced
왜 테스트하는지, 뭘 테스트할지, 언제 안 할지
테스트는 숨 참지 않고 코드를 바꾸기 위해 존재해. 어떤 프레임워크보다 먼저, 질문은 '내가 뭘 신뢰하려는 거지?' 야. 일하는 엔지니어 관점에서 왜 테스트가 존재하는지, 어떤 피라미드가 멀쩡한 test suite 의 모양인지, Vitest / Playwright / Jest / Cypress 중 뭘 고를지 의식 없이 결정하는 법까지 짚어.
설치, 설정, 단언, watch
Vitest 는 save 마다 30 밀리초에 테스트가 도는 빠른 inner loop 야. 설치하고, config 잘 잡고, 단언 어휘 익히고, watch + UI 모드로 테스트를 의식이 아니라 피드백 루프로 만들어. 네 lesson — 끝나면 Vitest 가 너의 프로젝트에서 돌고 방해 없이 자리 잡아.
함수, 모듈, 시간, 그리고 네트워크
Mocking 은 대상 unit 을 우주 나머지로부터 격리시켜줘 — 근데 모든 mock 은 네가 테스트에게 친 거짓말이고, 그 거짓말엔 비용이 있어. 네 종류 mock (함수, 모듈, 시간, 네트워크), 각각이 값어치하는 경우, 그리고 과용하면 마주칠 실패 모드를 익혀. 네 lesson.
RTL, 쿼리, user-event, async
React Testing Library (RTL) 가 컴포넌트 테스트의 각본을 뒤집었어 — 내부를 찌르는 대신 사용자가 하듯 렌더된 DOM 을 쿼리해. RTL 을 Vitest 에 연결하고, refactor 에 안 깨지면서 버그 잡는 쿼리 우선순위 익히고, user-event 로 인터랙션 구동하고, waitFor 를 도처에 안 쓰고 비동기 state 처리. 네 lesson.
두 번째 패스에서 손이 가는 것들
어드밴스드 트랙은 첫날엔 필요 없지만 둘째 주엔 필수가 되는 부분 다뤄 — coverage 리포팅 (그리고 측정 안 할 거), 테이블 기반 검증을 위한 parametrized 테스트, 단언 메시지를 가독적으로 만드는 커스텀 matcher, refactor 를 안 아프게 하는 type-safe 테스트 패턴. 세 lesson.
설치, 설정, 녹화, 디버그
Playwright 는 outer loop — 진짜 Chromium / Firefox / WebKit 가 너의 진짜 앱에서 진짜 버튼 클릭. 설치 제대로, dev 와 CI 둘 다 작동하는 config 짜고, codegen + headed-debug + UI-mode + trace-viewer 툴킷 익히고, 테스트가 브라우저 자체일 때 '이 테스트 믿어' 느낌을 느껴. 네 lesson.
Role 기반, web-first, auto-wait
Locator 가 Playwright 테스트가 초록으로 남는 단 하나 가장 큰 이유. Retry 하고, auto-wait 하고, default 로 접근성 우선 쿼리 — 단 그렇게 짤 때만. 이 트랙은 role 기반 selector 위계, 통과나 실패까지 retry 하는 web-first 단언, sleep 거의 안 쓰게 해주는 auto-wait 모델, suite 가 신뢰받게 유지하는 anti-flake 습관을 다뤄. 네 lesson.
Playwright suite 를 작동에서 ship 가능으로 데려가는 부분들
첫날 Playwright 테스트는 라이브 앱에 대해 돌고 작동. 프로덕션급 Playwright suite 는 결정적으로 네트워크 호출 mock 하고, 인증을 테스트 사이 재사용해서 로그인이 매 테스트의 첫 30초 안 되게 하고, setup 숨기는 커스텀 fixture 위에서 굴러가고, CI 에서 10분 미만으로 sharded 돌아. '작동' 에서 'CI 에서 이거 믿어' 로 다리 놓는 네 lesson.
뭘 테스트할지 결정하고, 너의 프로젝트에 적용
여덟 트랙의 도구와 패턴. 에필로그가 더 어려운 질문 묻기: 이제 거의 뭐든 테스트할 수 있는데, 뭘 테스트해야 해? 짧은 두 lesson 이 루프 닫아. 첫 번째는 테스트 예산 쓰는 결정 프레임워크 — unit vs integration vs E2E vs '테스트 안 함'. 두 번째는 이 원칙들 실제로 적용된 living 예제로 피파 본인의 frontend test suite 걸어봐.
아직 댓글이 없어요. 첫 댓글을 남겨보세요.