디자인시스템 유지보수 생산성 어떻게 올릴까? 시각적 회귀 테스트

1. 문제점

저희는 컴포넌트 스타일 라이브러리로 styleX를 선택했습니다.

전에 사용하던 styled-components는 여러 스타일을 상속받고 중첩하여 작성해서 다양한 스타일을 만들 수 있는 장점이 있었습니다.

하지만 css가 많아지고 중첩될수록 스타일을 예측하기 어려웠습니다.

왜 border가 생기는지, 어디서 backgroudColor가 생기는지 찾기 위해 스타일 파일을 한참 뒤적거려야 했습니다.

이런 불편함으로 인해 styleX가 스타일을 생각하는 방법에 공감했습니다.

’Don’t repeat yourself가 항상 옳지는 않다’라는 말인데요, 특히 스타일을 다룰 때는 컴포넌트와 가장 가까운 곳에 스타일을 위치시킴으로써 마크업과 가장 가까운 스코프에서 예측 가능한 스타일을 작성하면서 코드를 조금 반복하는 게 나을 수도 있다는 말입니다.

css 라이브러리에 관한 글은 아니니 여기에서 마무리 하겠습니다.

어쨌든 우리는 styleX의 생각에 공감했기 때문에 이것을 적용해보기로 했습니다.

기존에 작성된 컴포넌트를 하나씩 styleX로 마이그레이션 했습니다.

요구사항이 변경된 것이 아니기 때문에 전의 UI를 완벽히 동일하게 구현해야 했습니다.

하지만 로컬에서 storybook을 켜두고 스타일을 변경하면서 눈으로 확인을 하다 보니 실수도 잦았습니다.

실제로 모르고 넘어갈 뻔했던 예입니다. 모든 속성을 그대로 넣었는데도 borderRadius 속성이 적용이 안되어서 예상치 못한 변경이 생길 뻔했어요. 이런 것에 에너지를 빼앗기면 생산성이 급격히 안 좋아질 수 있습니다!

 

2. 해결방법

제 눈 대신 이러한 UI변경사항을 자동으로 포착(?)해줄 방법이 필요했습니다. 이런 테스트를 바로 시각적 회귀 테스트(Visual Regression Test)라고 합니다. 코드 변경 전/후의 스크린샷을 비교해 차이를 감지하고 UI의 시각적 일관성을 제공할 수 있도록 하는 테스트입니다. Chromatic은 storybook의 공식문서에도 나올 만큼 공식적으로 제공하는 테스트 도구입니다. 당연히 레퍼런스도 많습니다. Chromatic을 도입해서 시각적 회귀 테스트를 해보겠습니다.

 

3. Chromatic

Chromatic은 스토리북을 배포할 수 있는 서비스입니다. 스토리북이 빌드되면 클라우드에서 디자인시스템을 확인할 수 있습니다. URL을 통해 팀원과 함께 변경사항을 체크할 수 있고, 레포지토리를 연동해 주면 pr시에 UI TEST도 진행할 수 있습니다.

 

팀원들이 변경사항을 모두 확인하고 통과가 되면 모든 수정사항을 Accept 합니다.

 

 

그럼 UI test가 통과되고 merge가 활성화됩니다.

아주 좋은 기능인데요, 안타깝게도 저의 불편함을 해결하기 위한 도구는 아니었습니다.

 

 

diff(변경사항 체크)를 위해서는 변경한 내용을 origin에 push 하고 build 까지 완료되어야 하거든요.

이 시간이 보통 3분 이상 걸렸습니다. 개발 시점의 테스트 도구로는 적합하지 않습니다.

로컬에서 reference도 만들고 변경사항도 테스트할 도구가 필요합니다.

 

** 참고:

storybook에 Chromatic을 로컬에서 실행해서 visual test를 진행하는 플러그인도 있습니다.

이름은 @chromatic-com/storybook 입니다. 

위와 같이 원격에서 빌드한 후 클라우드에 올라가지 않아서 훨씬 빠르지만 여전히 스토리북 빌드 과정을 거칩니다.

스토리북에서 모든 테스트를 할 수 있다는 장점도 있습니다. 고려해볼만 합니다.

하지만 여전히 30초 이상 걸리기 때문에 저에겐 적합하지 않다고 판단했습니다.

 

4. Backstopjs

저의 요구사항을 만족하는 괜찮은 도구를 찾았습니다. Backstopjs 입니다.

yarn add -D backstopjs
backstop init

 

backstop init 명령어를 실행하면 루트 폴터에 /backstop_data/engine_scripts 폴더가 생성됩니다.

그리고 backstop.json 파일이 생성됩니다.

json에 설정을 그대로 입력해도 되지만, 복잡해질 예정이니 모듈로 관리하기 위해 backstop.config.js 파일로 수정하고 아래처럼 수정합니다.

module.exports = { ...backstop.json의 설정 }

단, config.js파일을 사용하게되면 명령어가 좀 복잡해집니다. 간편하게 스크립트로 만들어주세요.

"backstop:ref": "backstop reference --config=backstop.config.js",
"backstop:test": "backstop test --config=backstop.config.js",
"backstop:approve": "backstop approve --config=backstop.config.js"

세팅이 되었으면 비교의 원본이 될 reference를 만들어줘야 합니다.

원본이 되는 reference를 유지하고 변경사항을 스크린샷하여 reference와의 차이점을 비교할 겁니다.

yarn backstop:ref

위 명령어를 실행하면 backstop_data/bitmaps_reference 폴더가 생성되고 내부에 원본 스크린샷이 생성됩니다.

 

 

이제 일부러 변경사항을 만들고 테스트를 해보겠습니다.

yarn backstop:test

 

 

이번에는 backstop_data/bitmaps_test 아래에 테스트 스크린샷이 생겼습니다.

그리고 스크린샷으로 포착된 UI 비교 결과를 html문서로 보여줍니다.

 

 

혹시 변경사항을 눈으로 확인한다면 위 두 스크린샷의 변경점을 찾으실 수 있으신가요?

저는 어렵군요! 그럼 backstop이 보여준 html문서를 보겠습니다.

 

 

좋아요. failed가 1개 보이네요. ref 스크린샷과 test 스크린샷 간에 변경점이 있다는 뜻입니다.

 

 

DIFF를 자세히 보니 borderRadius의 예상하지 못한 변경이 있었군요!

맞습니다. 일부러 borderRadius를 2px 틀리게 입력했습니다. 위 과정이 약 2초가 채 걸리지 않습니다.

 

개발자 컴퓨터에서만 test와 diff가 이루어지기 때문입니다.

 

5. 결론

결과적으로 backstopjs를 도입하기로 했습니다.

저의 문제인 ‘스타일 수정 시 예상치 못한 변경점을 눈으로 찾아내기 힘들다’는 불편함을 빠르고 쉽게 해결할 수 있었기 때문입니다.

프론트엔드 개발자는 유저의 입장에서 항상 신뢰할 수 있는 모습을 보여주기 위해 노력해야 한다고 생각합니다.

시각적 회귀 테스트를 통해 우리가 어떻게 보일지 확신할 수 있게 되었고, 더 자신 있게 코드를 작성하게 되었습니다.

 

참고용: @chromatic-com/storybook 플러그인을 사용한 visual test 입니다.