우아한테크세미나: 시각적요소 테스트 자동화하기를 보고나서
우아한 테크세미나: 시각적요소 테스트 자동화하기
우아한형제들의 기술 조직에서는 기술 블로그 뿐만 아니라 다양한 방식으로 그들의 기술적인 경험을 공유하고 있는데, 우아한 테크 세미나 역시 우아한 형제들에서 겪는 기술적인 경험을 간단한 세미나 형태로 공유한다. 이번에 열린 세미나는 시각적 요소 테스트 자동화하기라는 주제로 1월 27 목요일에 유튜브 라이브로 진행되었다. 내용을 간단하게 요약하고 보면서 느꼈던 부분들에 대해서 작성하고자 한다.
테스트가 뭐에요? 왜 하는 건가요?
테스트란?
널리 사용되기 전에 어떤 것의 품질, 성능 또는 신뢰성을 확립하기 위한 절차
-
테스트를 통해서 무엇을 얻고자 하는가?
- 소프트웨어의 품질, 성능 또는 신뢰성
- 화면이 잘 그려지는가?
- 기능이 잘 동작하는가?
결국 전체 발표 전반에서 테스트의 목적은 안정성이라고 강조하고 있음.
어디에 무슨 테스트를 작성했나요?
무엇을 테스트 했나요?
- 만다오라는 툴을 테스트했음.
- 만다오는 사내에서 비 개발자가 GUI를 통해 마크업과 동작을 세팅하면 페이지를 퍼블리싱 해주는 툴
- 주로 이벤트 페이지 같은 정적 페이지를 생성할 때에 사용하고 있음
- 만다오 작업하고 배포 이후 화면 깨짐이나 다른 사이드 이펙트 발생 등 잠재 위험에 대비하기 위해 테스트를 도입
어떤 테스트를 했나요?
-
시나리오테스트
- 유저 시나리오를 작성해서 시나리오와 동일하게 동작이 되는지 테스트
-
- 렌더링 결과물이 기존과 같은지 스크린샷으로 스냅샷을 남겨서 비교해서 확인함
- CSS는 런타임 에러 등을 잡기가 어려워서 시각적 회귀 테스트를 통해 확인
어떻게 테스트했나요?
-
블랙박스 vs 화이트박스 테스트
- I/O 관점에서 테스트 vs edge case 포함 모든 내용이 정상적으로 실행되는지
=> 기존 서빙되던 페이지들이 정상적으로 서빙되는지 블랙박스 테스트
저도 테스트를 구성 해 보고 싶어요!
- 필요한 패키지 설치
jest-puppeteer,jest-image-snapshot사용- Config 작성
- 런타임 시점에 불리는 config는 ts로 작성함
- 테스트 작성
-
유튜브 임베드 부분은 제거함
- 유튜브 썸네일이 바뀌었을 때 리그레션 테스트 에러가 날 수 있기 때문에
- 테스트 구동
- 각 로컬 환경마다 테스트가 다른 경우가 있어서 docker를 활용해서 가상환경에서 테스트하게 하도록 함.
테스트를 작성하는게 진짜 좋은 일인가요?
에러 검거 사례를 소개
- 코드 수정했는데
- 예상하지 못했던 사이드 이펙트로 인해 에러가 발생함을 확인
찾은 에러보다 못찾은 에러가 무섭다.
레거시 코드 관리에 장점이 있다.
E2E 포함 모든 테스트를 우리가 해야할까?
- 테스트의 목적은 안정성 -> 최소한의 안정성을 보장
- 일정 중에 목을 조여오는 에러를 미연에 방지할 수 있다.
- 수정된 코드와 관련서잉 있는데, 막상 수동으로 테스트할 때에는 놓치기 쉬운 부분을 케어할 수 있다.
- 테스트 작성은 비용이긴 하기 때문에 장기적인 투자의 입장에서 바라보고 수행해야함.
- 한편으로는 테스트 작성에 그렇게 오랜 시간이 걸리지는 않으니 할만하다.
느낀점
rtl은 왜 사용하지 않았을까.. 충분히 접근할만한 좋은 라이브러리인 것 같은데, 만다오가 리액트로 작성된 프로젝트가 아닌가? 하는 생각이 들었다. 또, puppeteer를 이용한 테스트를 보면서 기존에 전통적이었던 enzyme과 같은 툴을 이용해서 테스트를 해왔던 것을 비교할 때에, rtl이 가지고 있는 테스팅 철학이 좀 더 트렌드에 맞겠다는 생각도 들었다.설명하는 부분의 대부분은 rtl로 충분히 테스트가 가능한 부분이 아닐까 하는 생각이 들었는데, 스크린샷으로 리그레션 테스트를 하기 위해 puppeteer까지 도입했어야했나? 하는 의문이 들었다.
또 rtl + jest 만으로 이미지 스냅샷 테스트를 할 수는 없을까? 하는 생각도 들었다. 스냅샷 테스트라는 것은 결국 이전의 스냅샷과 비교를 하는 것이기 때문에, 이전의 스냅샷이 무결하다라는 것을 전제하고 있을텐데, 이부분은 어떻게 보장하고 있는 것이맂 개발 프로세스에서 어떻게 정하고 있을지 궁금해졌다.
사실 처음 이 세미나를 듣게 된 부분도 맨 처음 언급된 CSS 디버깅과 같은 관점에서의 테스팅이 어떻게 되는지 궁금했고, 컴포넌트나 페이지가 디자인 시안과 어떻게 일치하는지 테스트하는 방법을 어떻게 하는지가 궁금했었다. 이 부분에 대한 해법으로 스크린샷을 활용한 스냅샷 테스트였다는 점은 흥미로웠다.
아무래도 프론트엔드 개발이 이전에 비해 많이 고도화 되면서 곳곳에서 프론트엔드 분야의 테스트가 꾸준히 강조되어오고 있는 것 같다. 테스트는 그간 내 큰 관심사 몇 개 중 하나를 차지하고 있는데, 그 이유는 테스트 코드가 갖는 효과가 안정성 확보에만 있다고 하기에는 너무 과소평과되는 것은 아닐까 하는 부분이다. 물론 안정성에는 단어에는 많은 의미를 담고있어서 이미 포괄하고 있는 ㅡ 사이드 이펙트에 대한 무결성을 확보하는 부분에 포함되는 이야기일 수 있겠지만, 테스트는 리팩토링의 기본이 된다는 점이다. 특정코드를 리팩토링할 때에 이전과 동일하게 동작함을 보장하려면 테스트코드가 필수라는 점이다. 그리고 내가 제일 중요하게 생각하는 부분은 테스트를 고려한 사고방식을 기른다는 것이다. 특히 관심사의 분리. 테스트를 할 때에 용이하게 테스트할 수 있는 방법에 대해서 고민하다보면 자연스럽게 관심사의 분리가 적용되는 코드가 작성되는 부분이 있는 것 같다. 테스트에 맞춘 꼭 필요한 부분만 존재하다보니 경제적이다. 이러한 점을 생각해볼 때, 자동화된 테스트를 통한 생산성은 이쯤되면 덤이라고 볼 수 있는 부분이다.
사실 발표를 들으면서 조금 의아했던 부분은 막상 테스트 작성에 그렇게 오랜 시간이 걸리지 않는다는 부분이었다. 유저 시나리오는 UI 요소가 생겨날 때마다 갯수만큼 경우의 수가 늘텐데, 과연 얼마 걸리지 않는게 맞을까? 또 개발을 하다보면 알겠지만 기획이나 디자인 단계에서 변경사항이라는 것은 자주 일어난다. 그러다보면 기존 테스트와 충돌도 많이 일어나서, 기존 테스트 코드도 관리하게되는 비용도 발생할 수 있다. 개인적으로는 테스트를 고려해서 개발하려고 하면 개발 프로세스 전반에서 테스트를 고려할 수 있게끔 변경해야한다는 생각이다. 테스트를 고려한 사고방식이 모든 사람들에게 필요하다는 의미가 된다 (생각만해도 너무 좋은 이야기다..). 길게 봤을 때에는 견고한 서비스를 위해 들일 만한 비용이라는 점에는 부정할 수 없다.