CSS 한 줄을 고쳤을 뿐인데, 전혀 다른 페이지의 버튼이 조용히 무너져 있습니다. 테스트는 하나도 실패하지 않았고, 리뷰에서도 못 잡았고, 일주일 뒤 사용자 제보로 알게 되죠. 작은 팀이라면 다들 겪어본 버그일 겁니다.
교과서적인 답은 “유닛 테스트를 더 쓰세요"입니다. 저도 소규모 개발팀을 맡고 있지만, 솔직히 모든 컴포넌트와 레이아웃 상태에 유닛 테스트를 쓸 여유는 없습니다. 대신 기대는 게 비주얼 테스팅입니다. 페이지 스크린샷을 찍고, 정상 상태의 베이스라인과 비교해서, 움직이면 안 되는 픽셀이 움직이면 빌드에서 알려주는 방식이죠. 들어가는 노력을 생각하면 이만한 게 없습니다.
스크린샷이 제 몫을 하는 이유#
매력은 “안 써도 되는 것들"에 있습니다. 비주얼 테스트는 개별 요소에 assertion을 다는 게 아니라 페이지 전체를 통째로 판정합니다. 레이아웃 밀림, 색상 변화, 반응형 깨짐, 요소 겹침. 코드 리뷰에서 놓치기 쉽고 유닛 테스트로 커버하자면 고행이 되는 것들인데, 이게 전부 PR 안의 diff로 나타납니다.
유지보수도 거의 제로입니다. 베이스라인을 한 번 잡아두면 PR마다 자동으로 돌고, 매번 같은 결과가 나옵니다. 의도한 UI 변경이면 베이스라인을 업데이트하고 넘어가면 되고, 의도하지 않은 변경이면 diff가 PR에 떠 있으니 사이트 절반을 클릭하며 돌아다닐 필요가 없죠.
유닛 테스트를 대체하지는 않습니다#
유닛 테스트는 로직을, 스크린샷은 외관을 검증합니다. 결국엔 둘 다 필요합니다. 다만 작은 팀이라 처음 몇 시간을 어디에 쓸지 골라야 한다면, 셋업 시간 대비 커버리지는 비주얼 테스트가 최고입니다. 제 기준은 이렇습니다. 깨지면 정말 아픈 비즈니스 로직에는 유닛 테스트, 나머지는 비주얼 테스트.
시스템은 이게 전부입니다. 베이스라인, PR마다 뜨는 diff, 그리고 가끔 “네, 의도한 변경 맞습니다” 클릭 한 번. 그런 것치고는 기대 이상으로 많이 잡아줍니다.
추가 정보 및 유용한 링크#
Visual Testing with Playwright#
Playwright 스냅샷 테스트 문서입니다. 전체 페이지나 특정 요소를 캡처해 베이스라인과 비교하는 방법, 의도적인 UI 변경 시 베이스라인을 갱신하는 방법을 다룹니다. Visual Testing with Playwright
Best Practices for Testing with Playwright#
데이터베이스를 건드리는 테스트에 대한 Playwright의 권장 사항입니다. 테스트 데이터 격리, 테스트 후 정리, 테스트 간 독립성 유지가 핵심입니다. Best Practices for Testing with Playwright