바닥부터 시작하는 Vue 테스트와 리팩토링 from if kakao 안녕하세요. 카카오 FE플랫폼팀 Lumi입니다. 얼마 전 열렸던 kakao FE(Front end) meetup 행사에서 바닥부터 시작하는 Vue 테스트와 리팩토링이라는 주제로 발표를 맡았고, 그때 발표했던 내용을 글로 재구성해 보았습니다. 들어가기 앞서, 테스트 방법은 다양하고 이 글에서 제시하는 방법이 정답이 아닐 수도 있지만 더 좋은 테스트와 테스트하기 좋은 코드를 탐구했던 과정을 공유하는 것에 가치를 두고 읽어 주셨으면 합니다. 이 글은 Vue 컴포넌트 테스트를 작성하며 알게 된 지식과 함께, 작성 과정 중 했던 생각들, 팀 안에서 관련 주제로 나눴던 대화들을 다룹니다. Vue와 유닛 테스트의 기본적인 경험을 가지신 분들을 대상으로 글을 작성했으며, Vue 컴포넌트 테스트는 어떻게 시작하면 좋을지, 컴포넌트에서는 무엇을 테스트하는 게 좋을지 궁금하신 분들께 도움이 될 것 같습니다. 배경 제가 카카오에 입사하여 1년이 조금 안 되는 기간 동안 계속 맡고 있는 프로젝트 소개를 간단히 드리면서, 테스트를 시작하게 된 배경을 말씀드리려고 합니다. 위에 보시는 화면은 제가 맡고 있는 Kakao for Business라는 웹사이트 화면인데요. 카카오의 비즈니스 사용자를 위한 통합 플랫폼이라서, 아마 대부분은 처음 보실 수도 있을 것 같습니다. 이 프로젝트는 Nuxt 기반의 Vue 컴포넌트로 이루어져 있습니다. 처음에는 기존에 개발하셨던 분과 같이 업무를 하다가, 인수인계를 받고 어느 날부터 혼자 운영을 하기 시작했습니다. 그러던 어느 날, 이야기가 시작됩니다. 기존에 구현되어 있던 코드량도 많고, 로직도 복잡한 몇몇 덩치 큰 Vue 컴포넌트들이 있었는데요. 이 쪽의 유지보수가 꾸준히 들어오면서, 저는 무럭무럭 덩치를 더 키우게 됩니다. 기존 구조를 유지하면서 기능 추가를 하다 보니 당연한 이야기지만 점점 수정하는데 들이는 비용이 커지게 됐어요. 프로젝트를 맡은 초반에 기존 코드를 재빠르게 리팩토링 하지 못해 점점 심리적 부담이 늘어났습니다. 그래서 저는 리팩토링이라 말하며, 제 눈에 익숙한 코드로 바꾸고 싶은 욕구를 저희 파트의 Paul에게 드러냈습니다. Paul이 대답하셨어요. QA를 거치고 운영되는 코드는 귀한 코드입니다. 테스트 코드 없이 리팩토링 완성을 어떻게 보장할 수 있을까요? 가시적으로도, 안정성면으로도 테스트 코드가 필요할 거예요. 테스트 코드와 함께 리팩토링 하는 것을 추천해요. 다만, 기능 추가와 리팩토링을 같이 하지 말 것이라고 추가로 가이드도 주셨습니다. 테스트를 시작한 이유 보통 테스트라고 하면, TDD를 많이 떠올리실 것 같은데요. 앞선 Paul과의 대화에서도 알 수 있듯이, 테스트를 먼저 만들지 않았더라도 운영 중인 코드를 수정할 때 코드의 안정성을 돕고, 리팩토링이라는 추상적인 진행상황을 가시적으로 측정할 수 있게 해주는 역할이 있기 때문에 필요성을 공감했어서 테스트를 시작하는 첫 번째 이유가 되었습니다. 그리고 저는 운영 업무 외에도 업무 안

안녕하세요. 저는 Spoqa 개발팀의 Jay라고 합니다. 저는 이번에 도도포인트 앱의 프론트엔드를 재작성하는 프로젝트를 진행했는데, 새로운 프론트엔드 개발 환경을 구축하고 싶으신 분들께 도움이 될까 하여 경험을 공유해봅니다.도도포인트의 경우스타트업은 유연한 조직 구조와 빠른 제품 개발 속도로 기존의 기업들을 앞지를 수 있습니다. 스포카는 도도포인트라는 서비스를 운영하는 스타트업으로서, 고객들이 원하는 제품에 대한 기능들을 빠른 속도로 제공해 줄 수 있어야 하며, 또한 서비스는 안 정적이어야 합니다.도도포인트 서비스는 빠른 개발 속도를 만족시키기 위해 HTML5 기반의 SPA(Single Page Application) 구조를 가지고 있습니다. 간단히 말하자면, 웹앱 서비스라고 볼 수 있습니다. 기존 앱은 Backbone 등의 라이브러리들을 이용해 작성되어 있었습니다.Backbone은 현장에서 충분히 많이 사용하므로, 검증된 라이브러리라 할 수 있습니다. 소위 말하는 battle-tested lib인 것입니다. 하지만 많은 사람들이 사용하는 것이 문제를 자연히 해결해 주지는 않습니다. 수년간의 개발 진행 후 도도포인트 앱은 더이상 scale up이 버거울 정도로 커졌습니다.기존 앱을 수선할 것인가, 재작성할 것인가너무 자세하게 이야기하면 주제가 바뀔 수 있는 바, 스포카 개발팀이 겪고 있었던 문제를 간단하게 이야기하고자 합니다.도도포인트는 빠른 개발 속도가 중요하다 보니 요구사항이 충분히 잘 정의되지 못한 상태에서 스케일업을 할 때가 많았습니다. 그러다보니 자연히 모듈과 함수들의 정의 또한 잘 정의되지 못하고, 재사용성이 떨어지는 코드를 작성하게 되었습니다 (주관적인 견해이나, Backbone은 lightweight JavaScript MVC를 지향하다 보니 그에 따른 장점도 있지만 추상화가 어렵고 장황한 코드를 작성하게 되는 경향이 있다고 생각합니다. 이를 보완하는 여러가지 라이브러리들이 있긴 하지만, 도입하기에는 이미 늦은 상태였습니다). 이는 자연히 유닛 테스트의 부재 등 여러가지 이슈로 이어지게 되었습니다.이러한 문제로 점점 개발 속도는 느려지게 되었으며 SPA 앱의 특성상 장애또한 빈번하 게 발생하게 되었습니다. 이런 앱 구조에 대한 문제의식을 계속 가지고 앱을 개선해 나가던 와중, 프론트엔드를 재작성하자는 이야기가 개발팀 안에서 조금씩 나오기 시작했습니다.개발자라면 한번쯤은 들어봤을 법한 글이지만, Joel Spolsky는 Things You Should Never Do에서 앱을 재작성하는 것은 절대 해서는 안될 일이라고 주장한 바가 있습니다. 그의 논지는 충분히 설득력이 있습 니다. 하지만 앱을 단순히 재작성하는 것이 아닌, 더 좋은 도구들을 이용하기 위한 기반을 만드는 것이라면 어떨까요?더 새로운 것은 더 좋은 것이다. 아마도Finally a JavaScript book from O'Reilly that just speaks to me pic.twitter.com/Eg7F91KwLb — λ