CI에서 수행되지 않는 스냅샷 테스트는 매우 편리합니다.

웹 프런트엔드 개발에서는 일반적으로 스냅샷 테스트를 실시하는데 자신이 만든 서비스를 가져오고 싶지만 다음과 같은 이유로 가져오기가 어렵다.

애니메이션 요소가 있는 화면이 많고 타이밍이 조금 어긋나면 차별이 생기기 쉽다

따라서 CI 통과 또는 드랍 비용을 부담하고 싶지 않음

따라서 스냅숏 테스트라기보다는 외관의 차이를 보다 간단하게 전면적으로 검사하기 위해 CI에서 스냅숏 테스트를 실시하지 않고 수중에 실행한 결과의 이미지를 제출하는 조작이 매우 편안하다.

CI는 아니지만 주변의 외관 차이 여부를 전체적으로 확인

특히 CSS를 대량으로 수행하는 팩스 작업과 겹쳐 스냅샷에 차이가 없으면 과감하게 팩스 처리를 할 수 있다

애니메이션 등의 Flaky로 인해 테스트 실패로 인한 불쾌감을 피하기 위해 항상 -u 플래그를 달고 실행

애니메이션에서 차이가 나는 상황에서 어쩔 수 없는 일로 인류는 눈으로 보고 참여하지 않는 잡다한 운용😇

threshold 등에 주의를 기울일 필요가 없고, CI에서 스냅샷 테스트를 할 때의 Flaky

를 상대해야 한다.
단점은 CI에서 시행하지 않고 주변에서 시행하지 않는 멤버가 있으면 차별을 모른다는 것이지만, 이는 도입 전과 같은 것이어서 개의치 않는다는 것이다.
스토리북을 도구로 사용하기 때문에 스토리샷을 사용하고 싶었지만 스토리샷은 제스트에 의존해 수중에 있는 Vite+Jest의 환경이 정리되지 않아 플레이 wright를 사용했다.
https://playwright.dev/
Play wright은 이런 느낌의 API입니다.

test('snapshot test', async ({ page }) => {
  // top page
  await page.goto('http://localhost:3000/');
  await page.locator('text=Top').waitFor();
  expect(await page.screenshot()).toMatchSnapshot('top.png');
});

Playwright는 Storyshots와 달리 구축 구성이 어떻든지 상관없이Vite/React가 아직 시들지 않은 환경에서도 문제없이 가져왔다.로컬 등에 인터넷 애플리케이션을 구축할 필요가 있지만 로컬 개발에서 사용하기 때문에 나쁠 게 없다.