간단 배경 설명
아토믹 디자인 패턴 도입하면서 몇 가지 한계점이 보이기 시작하였다
- 하나를 조금만 바꿔도 전체가 망가지는 상황이 생김
- 예를 들어, base swiper 에서 height 하나 조정했더니 메인이 이상하게 꼬여버림
- 이유는 메인에 스와이퍼가 있어서 그런 것
- 그래서 코드 변경하는 걸 좀 망설이게 되었고
- 페이지가 망가지는 걸 막기 위해 여러 방어 로직을 넣기 시작했는데,
이런 코드들이 개발자들 간에 오히려 혼란을 주고 있었음
그래서 생각했다
누군가 매번 지켜보고 있다면 이런 문제가 없지 않을까?
여기서 '누군가 지켜보고 있다'는 건 >> 테스트 코드라는 생각을 했다
데이터 중심의 유닛 테스트는 인증 같은 명확한 로직에는 잘 맞지만,
시각적인 변화를 테스트하기에는 한계가 있겠다는 생각이 들었다
“시각적” 테스트 코드에 대해 알아보다 보니,
CSS 까지 테스트 코드에 넣는 건 정말 큰 일이라는 걸 알게 되었고 (FE 개발자 혼자서는 힘든 일임을 깨달음)
스토리북이 시각적 테스트 코드에 대한 해답을 줄 수 있을 것 같았는데,
스토리북은 다른 팀과 협업할 때 쓰는 "문서"로 쓰는 게 더 나을 것 같다는 생각이 들었다
그래서 컴포넌트가 바뀔 때마다 자동으로 지켜보고 검사까지 해주는 도구를 찾아 봤는데,
스토리북 만든 Chromatic 에서 그런 기능을 지원한다는 걸 알게 됐지만, 유료라는 게 좀 걸렸다 과연 회사에서 지원해 줄지 모르겠음
계속 찾아보다가 Backstop.js 를 찾게 됐다
Backstop.js 가 뭘까
시각적 회귀 테스트를 위한 라이브러리이다
회귀 테스트란, 테스트가 완료된 프로그램에서 변경 사항이 발생했을 때,
변경이 기존 기능에 영향을 주지 않았는지 확인하기 위해 반복적으로 수행하는 테스트이다
이 과정에서 새로운 결함이 발생했거나, 이전에는 발견되지 않았던 결함을 찾아낼 수 있다
시각적 회귀 테스트는 이러한 회귀 테스트를 시각적으로 수행할 수 있게 해주는 방법이다
UI의 변화를 포착하고, 의도치 않은 스타일 변경이나 레이아웃의 깨짐 등을 쉽게 감지할 수 있다
외국에선 VRT 라고 불리운다 (Visual Regression Test)
Backstop.js 를 어떻게 활용할 수 있을까
일단 내 아이디어는 아래와 같다
- PR 이 생성될 때 > Backstop 테스트를 실행
- Backstop 테스트에서 UI 가 변경되었다면 > Teams 로 메시지를 보냄 or 봇이 PR 에 댓글을 닮
- 여기서 문제는 PR 에서 팀즈로 전송이 가능한지, 댓글 달아 줄 봇이 있는지 찾아봐야 함
- 가능하다면 그 봇이 막강한 힘(?) 이 있어서 확인 전까진 merge 가 안 되는 그런 권한도 넣었으면 좋겠음
- 개발자는 팀즈나 댓글을 본 뒤 의도한 게 맞다면 머지 시
'프론트' 카테고리의 다른 글
IDE 켜지면 저절로 node 버전 셋팅되도록 하기 (0) | 2024.03.10 |
---|---|
VSCode 익스텐션 만들기 (0) | 2023.09.13 |