#Testing

TDD와 BDD는 둘 다 '테스트 먼저'라는 철학을 공유하지만, 초점과 사용 방식이 다르다. Red-Green-Refactor 사이클부터 Gherkin 문법까지, 실전 TypeScript 예제로 비교해봤다.

테스트에서 fetch를 직접 모킹하거나, axios를 vi.mock()으로 교체하다가 실제 API와 차이가 생겨 고생한 적 있다. MSW는 네트워크 레벨에서 요청을 인터셉트해서 그런 문제를 근본적으로 해결한다. 설정부터 Vitest, Storybook 통합까지 정리했다.

유닛 테스트가 전부 초록불인데 QA가 클릭 몇 번 만에 버그를 찾아낸다. E2E 테스트가 없어서다. Playwright로 실제 브라우저에서 사용자 시나리오를 자동화하는 법을 처음부터 정리했다.

백엔드 API가 준비되지 않아 프론트엔드 개발이 멈추는 문제를 MSW(Mock Service Worker)로 해결했다. 네트워크 레벨 API 모킹의 원리와 실전 패턴.

vi.mock()과 vi.spyOn()의 차이를 몰라 밤새 디버깅한 적이 있다. 스냅샷 테스트가 언제 독이 되고 약이 되는지, 커버리지 숫자가 왜 거짓말을 하는지 — 실전에서 배운 Vitest 심화 전략을 풀어본다.

복잡한 페이지 깊숙이 있는 컴포넌트를 수정할 때마다 로그인을 다시 하고 클릭을 5번 해야 하나요? Storybook으로 컴포넌트를 격리(Isolation)해서 개발하는 CDD 방법론.

테스트 커버리지 100%를 달성하고 기분 좋게 배포했지만, 프로덕션은 에러를 뱉어냈습니다. 원인은 '가짜 객체'를 남발한 것. Mock, Stub, Spy의 차이를 정확히 모르고 사용하다가 겪은 실패담과 올바른 테스트 대역(Test Double) 사용법을 정리했습니다.

한때 저는 테스트 커버리지 100%를 달성하기 위해 집착했습니다. 모든 줄에 초록색 불이 들어오자 안심하고 배포했지만, 결과는 치명적인 버그였습니다. 커버리지가 알려주지 않는 것들과 의미 없는 테스트의 위험성, 그리고 진짜 중요한 테스트 지표에 대해 이야기합니다.

테스트 유형별 차이와 활용

코드를 먼저 짜고 테스트하는 게 아닙니다. 테스트를 먼저 짜고, 그걸 통과하기 위해 코딩하는 것. 순서를 뒤집으면 버그가 사라집니다.

유닛 테스트가 다 통과해도 배포하면 에러가 나는 이유는 뭘까요? 사용자가 실제로 사용하는 흐름 그대로를 검증하는 E2E(End-to-End) 테스트가 필요합니다. Cypress와 Playwright의 장단점 비교, 깨지기 쉬운(Flaky) 테스트를 방지하는 전략, 그리고 테스트 피라미드 속 E2E의 역할을 정리합니다.

코드 푸시하면 로봇이 테스트하고(CI), 로봇이 배포합니다(CD). '내 컴퓨터에서는 잘 됐는데'라는 변명은 이제 안 통합니다. 자동화 파이프라인으로 하루 100번 배포하기.