스냅샷 테스트의 한계

휴먼 에러

애플리케이션의 코드가 계속 변화에 따라 UI 구조가 변경되면 스냅샷 테스트는 실패하게 되고, 개발자는 의도한 변화이니 스냅샷을 업데이트 하게 된다. 그런데 이 과정이 아주 많이 반복되면서 스냅샷 테스트 실패의 원인을 면밀히 살펴보지 않고 단순히 변경된 UI 구조 때문일거라 생각하고 쉽게 업데이트를 해버린다면, 버그를 찾지 못한다는 테스트 본연의 기능을 다하지 못하게 된다.

UI 변경사항

jsDOM 스냅샷은 DOM 트리를 비교하기 때문에 그게 반드시 올바른 렌더링을 보장하지 않는다. CSS 속성이 변경되면 최대 해당 컴포넌트의 레이아웃이 재배치될 만큼 큰 변화가 발생할 수 있는데, 스냅샷 테스트에서는 같은 DOM 구조를 가지기 때문에 변화를 감지해낼 수 없다.

TDD 부적합성

TDD 사이클 내에서 스냅샷 테스트를 수행할 경우 상황에 맞게 스냅샷을 업데이트 하지 않는다면 테스트가 항상 실패하게 된다. 그래서 그 사이클 안에 개발자가 업데이트 여부를 판단하기 위한 과정이 추가되어 TDD 사이클과 맞지 않는 방식으로 테스트를 작성하게 된다.

Don't Rely on Snapshot Tests #

Ever since I started working with React in 2016 I’ve had only one situation in which snapshot tests have caught a problem in my components. A call to new Date() without an argument had slipped and it always defaulted to the current date.

Besides this, snapshots have only been a cause for failed builds when a component is changed. The usual workflow is to make a change to the component, see that snapshots are failing, update them and proceed.

Don’t get me wrong, they are a good sanity check but they are not a replacement for good component level tests. I avoid even creating them anymore.

• Alex Kondov, Tao of React

시각적 회귀 테스트

위의 Alex Kondov의 언급처럼 프론트엔드에서 스냅샷 테스트는 거의 사용되지 않는다고 한다. 그래서 이 한계를 극복하고 스타일과 레이아웃에 대한 변경사항까지 감지할 수 있는 방법인 시각적 회귀 테스트를 사용한다.