📌 서론
저희 회사에서는 팀 단위로 한달에 한두번씩 모여 공부하는 활동을 진행하고 있어요. 팀들은 각자 하나의 큰 틀을 가지고 공부하게 되는데, 제가 속한 이번 팀의 주제는 테스트 자동화에요. 테스트 자동화, 개발자라면 필수적으로 거치는 테스트라는 프로세스를 자동으로 실행하고 검사해준다니 매력적이지 않나요😝? 그래서 오늘 이 시간에는 며칠동안 공부했던 테스트라는 주제와 프론트엔드 개발자의 테스트에 대해서 알아볼게요👏👏👏.
📌 개발자에게 테스트란?
테스트란?
애플리케이션이 요구 사항에 맞게 동작하는지를 검증하는 행위
일반적으로는 결과물이 사용자에게 전달되기 직전 거치는 QA(Quality Assurance) 기간 동안의 과정을 테스트라고 해요. 그러나 실제로 살펴보면 이런 검증 과정은 모든 단계에서 꾸준히 이루어지죠. 간단한 UI 문구 수정부터 시작해 특정 동작을 실행하는 기능 개발까지, 멘먼스와 관계 없이 테스트는 어떤 사이트든 반드시 필요한 프로세스에요.
최근에 회사에서 사용자가 물리 버튼을 누를때와 화면 상 뒤로 가기 버튼을 눌렀을때 동작하는 기능이 다른 이슈가 있어 이 둘의 싱크를 맞추는 작업을 진행한 적이 있었어요. 겉으로 봤을때는 기존에 뒤로가기 버튼을 물리버튼 동작시에도 똑같이 동작하도록 하는 간단한 작업처럼 보이지만 실제로는 컴포넌트에 적용된 css와 디자인을 비교하고, 적용한 기능이 웹에서는 정상적으로 작동하는지, 앱의 운영체제 별 동작이 동일한지, 사이드 이펙트는 발생하지 않았는지 등 사소할 수 있는 부분들 하나하나를 다 검수하며 테스트를 진행하게 되었습니다.
*출처:https://terms.naver.com/entry.naver?docId=3574802&cid=58881&categoryId=58891
다양한 관점에서 바라보고 테스트를 진행하면 할 수록 해당 기능은 더욱 견고해진다는건 당연한 이치. 그러나 기능이 커지고 경우의 수가 많아질수록 보이지 않는 문제가 생기는 법, 이런 사각지대로 인해 예측하지 못한 문제들이 발생하게 되면 개발자는 발등에 불이 떨어지고 야근의 늪으로 빠지게 됩....😭
개발자도 당연히 사람인지라 모든 경우의 수를 찾아내 완벽한 결과를 보장하는 테스트를 해볼수는 없어요. 더구나 시간적으로 여유가 없을땐 이런 실수를 범하기 더 쉬워지죠. 이러한 상황에서 테스트 자동화 환경 구축은 좋은 대안이 될 수 있다 생각합니다✌.
📌 TDD(테스트 주도 개발)
일반적인 개발의 경우 요구사항이 정의되면 디자인 , 개발 그리고 테스트라는 하나의 과정을 거치게 돼요. 테스트가 만족스럽지 않을 경우 요구사항을 보완하고 다시 이 과정을 반복하게 되죠.
요구사항은 처음부터 명확하지 않을 수 있고, 처음부터 완벽하게 설계한다는건 힘들기에 재설계를 거듭해야만 완벽한 개발이 가능합니다. 재설계는 개발자에게 반복적인 코드 삽입 또는 삭제로 인해 소스코드의 품질을 저하시킬수 있고 결국 테스트에 대한 비용이 과해질수 있다는 단점을 갖고 있죠. 이런 단점들을 해소해줄수 있는게 바로 테스트 주도 개발이에요.
TDD
TDD(테스트 주도 개발)이란 자동화된 테스트 코드를 미리 짜두고 이를 통과시키는 코드를 반복하여 구현하는 소프트웨어 방법론입니다. 에자일 방법론 중 하나인 eXtream Programming(XP)에 기반을 두었기 때문에 예측보다는 경험을 통해 지속적으로 프로토타입을 완성해가는 방식입니다. 실패하는 코드와 성공하기 위한 코드를 둘 다 테스트한다는 것은 기대되는 결과를 명확하게 정의하게 되고 불필요한 설계에 대한 자원낭비를 방지 할 수 있습니다.
(테스트 도중 발생하는 문제들은 테스트 케이스에 추가하고 이를 통해 개선된 설계는 재설계 시간에 대한 절감해준다. 또한 통과된 케이스만을 실제 코드로 옮기기 때문에 반복적인 삽입과 삭제가 줄어들어 간결한 코드 작성이 가능해진다.)
프론트엔드 개발자는 웹의 영역 중 눈으로 볼 수 있는 부분의 ui와 기능을 구현해요. 사용자가 ui를 직접 확인하며 경험을 가질수 있기 때문에 기획자,디자이너와 가깝고 서버에서 받은 값을 가공하기 때문에 백엔드와도 가깝죠. 중간에 껴있기 때문에 프론트엔드 개발자는 의견을 전달하고 조율하는 역할이 크다고 할 수 있죠😎😎😎. 매끄러운 작업을 위해 가장 중요한 사항은 전달 받은 요구사항에 대해 개발 후 어떤 문제가 발생할 수 있는지, 보완점과 불필요한 부분에 대한 파악이라고 생각해요. 때문에 TDD는 문제점이 발견되었을 때 기획자는 재설계를 , 개발자는 테스트 케이스 추가를, 서로에게 부담을 주지 않는 선에서 협업하며 기능을 완성해나갈수 있는 좋은 방법론이라고 생각합니다👍🏼.
📌 JEST를 이용한 테스트
jest는 페이스북에서 개발한 javascript 단위 테스트 프레임워크입니다. Zero configuration 철학을 가지고 있어, 특정 서버 없이 빠르고 단순하게 사용이 가능하다는 장점을 가지고 있어요. 과거에는mocha, jasmin,chai 등 여러 라이브러리를 조합해야 테스트를 할 수 있어 테스트 과정이 꽤나 순탄하지 않았다는데 이 모든 기능을 jest는 한번에 제공해준다고 합니다.
빠르게 변하는 생태계에서 이렇게 오랜 시간 높은 점유율을 자랑한다는건 그만큼 만족도가 높기 때문 아닐까?
테스트하고 싶은 파일을 목표(expect)로 설정해 기댓값(toEqual, toBe 등)과 비교해 볼 수 있다.
컴포넌트에 대한 테스트(돔에 접근해 값을 비교하는 것이 가능하다)
coverage를 통해 테스트 진척률을 확인 할 수 있다.
coverage 분석 리포트 html도 제공
📌 장점 및 단점
내가 작성한 코드에 대해 자동으로 테스트를 해주는건 새로운 경험이였어요. 작성이 필요한 문법이나 로직도 복잡하지 않아 초기에 환경 세팅만 잘 해두면 꽤나 유용하겠다 싶네요.
사실 테스트 자동화가 가진 장점들에 대해서는 그 누구도 부정하지 않을거라 생각합니다. 어쩌피 해야하는 테스트를 알아서 해주고 결과 까지 분석해서 보여준다니, 이거야 말로 금상첨화 아닐까요? 그럼 앞으로 진행되는 모든 테스트는 테스트 자동화가 역할을 대신 하게 되겠네요? 그렇지 않습니다. 테스트를 자동화하기 위한 테스트 코드에 대한 작성 역시 시간과 비용이 들어가기 때문인데요. 한 눈에 봐도 알 수 있는 간단한 코드들까지도 테스트 코드를 작성하게 된다면 오히려 테스트 코드 작성 시간대비 그만큼의 효과를 보지 못해 과유불급 현상이 나타날 것이라 생각합니다.
만약 현재 사이트에 테스트 자동화를 적용하게 될 경우 불필요한 소스는 제거하고 오류가 발생 할 수 있는 부분에 대해서만 테스트 코드만을 작성하여 최소한의 유지 보수 비용을 가져가는 것이 중요하겠다 생각했습니다. 때문에 테스트 케이스를 적용할 범위나 규칙을 사전에 정해두고 본격적인 테스트 코드를 작성하는 것이 추후 반복되는 개선 요구사항과 코드 개선 과정에 도움이 되지 않을까 하는 생각입니다.
장점
- 빠른 피드백으로 인한 요구사항 개선
- 코드 재생산성 확대
- 불필요한 소스에 대한 개선 및 처리
단점
1.테스트 코드 품질이 좋지 않을 경우 과도한 시간 소모 가능
2. 테스트 코드 작성으로 인한 생산성 저하
📌 후기
테스트 코드를 작성하는게 처음이라 환경설정하는데만 꽤나 애를 먹었다. 컴파일 문제부터 시작해 vue 확장자 인식 실패 에러 등... 기본적인 테스트 환경만 갖추는데 과장해서 1달 정도는 쓰지 않았나 싶다.
처음에는 왜 굳이 이렇게 긴 시간을 들여서 테스트를 해야되는거지? 심지어 테스트도 아니고 테스트 환경 설정인데... 그냥 vue-cli로 하면 jest 뿐만 아니라 e2e까지 가능한 환경을 쉽게 제공해준다는데 갈아탈까 싶어 몇번 프로젝트를 엎은 적도 있다. 그러나 결국 다 필요한 경험이였거늘.. 이제보니 지난 1달이 보람까진 아니여도 의미 없던 시간은 없지 않았나 싶다(내 무지함이 문제일 뿐..). 비록 짧고 복잡하지 않은 코드로만 작성했지만, 기본적인 세팅만 잘 해두면 프로토타입의 완성에 대한 접근 및 소비 시간은 더 빠르지 않을까 싶다. 언젠가는 이런 테스트 위주의 프로젝트도 경험해보면 괜찮겠다 싶은 생각이 들었다.
다음은 vite와 vitest를 한번 사용해볼까 한다. 주변의 경험 만족도가 꽤나 높은 점, 내가 개발자의 가치관으로서 존경하는 evan you가 만들었다는 점 그리고 분석 차트를 맹신하는 나에게 vitest의 높은 점유율은 이미 호기심을 가지기에 충분했다.
//참조
https://2022.stateofjs.com/en-US/
나만의 성장 일기