[모닥불] EP3. 테스트 자동화에 대한 영상을 보고..

개요
1. 테스트 자동화가 필요한 이유
2. 테스트 코드의 종류
3. 앞으로 해볼 도전

 

 

toss tech에서 새롭게 영상이 올라와서 시청하게 되었다...

현재 취업과 개발 실력을 향상시키는 방법 중에 고민이 되는 것이 디자인 시스템을 공부를 하는 것과 테스트 코드를 공부 하는 것 크게 2가지가 있었고 이전에 Figma API를 이용한 디자인 시스템 구축 및 라이브러리 만들어보기라는 매력적인 계획을 세워 놓은 상태에서 영상을 시청하게 되었다.

 

 

---

 

 

🔶 테스트 자동화가 가지는 Benefit

---

본문에 들어가기 전 한가지 유의해야할 점으로 테스트 자동화는 무식하게 모든 부분에서 사용되는 것이 아니다. 사용되는 테스트의 종류도 다양하고, TDD를 고수하는 것이 아니며 방어적인 목적으로도 사용 가능하다 

 

🎈생산성의 향상

아래에 나올 모든 내용이 귀결되는 것으로 코드를 작성하고 점검하는 것에 대해 생산성이 향상되는 것이 테스트 코드의 가장 큰 강점이다.

1. 피드백 사이클이 빨라진다.
   • 원하는 동작을 코드로 바로 확인할 수 있어 특히나 사용자에게 많은 정보를 받는 form의 경우 직접 구현하는 것보다도 테스트 코드는 피드백 사이클이 빠르다.
2. 코드의 수명이 늘어난다.
   • 프론트엔드 코드는 요구사항과 여러 요인에 따라서 변화가 매우 많은 코드이기에 코드 하나하나가 가지는 수명이 굉장히 중요하다 생각되며 이러한 테스트 코드를 작성함으로 이러한 코드의 퀄리티 및 수명을 늘릴 수 있다.
3. A / B 테스트에서의 강점
   • 일일이 조작하여 테스트하지 않고도 손 쉽게 A / B 테스트가 가능하다.
4. 내가 원하는 테스트에만 집중할 수 있다.
   • 내가 테스트하고 싶은 코드에 대해서 외부 의존성이 복잡하면 다양한 요건을 고려해야하므로 원하는 로직에 대한 검증만 하기 힘들어진다. 그렇기에 외부 의존성을 낮춰 내가 원하는 검증을 할 수 있어 피드백 사이클 또한 짧아질 수 있다.(Feature Flag에서의 테스트)
5. 안정성 있는 로직
   • 테스트 코드를 통해 신뢰성을 확보한다면 보장된 안정성이 있기에 배포에 있어 자신감 있어진다.
6. 스펙으로써의 가치
   • 스타트업의 경우 문서화를 명확히 제공하지 못하는 경우가 많은데 이러한 경우 이터레이션을 명시적으로 나타내기 힘들다 하지만 잘 짠 테스트 코드는 이러한 경우에 완성된 문서로써 신뢰할 수 있는 스펙 문서가 된다.
7. 초단기적 생산이 아닌 단기적 생산
   • 테스트 코드를 작성하는데 소요되는 자원이 있는만큼 초단기적인 측면에서는 직접 테스트를 하는 것이 빠르겠지만 이러한 경우 QA에 의존하게되고 단기적으로 보았을 때 유지 보수에 대해 테스트 코드를 작성하는 편이 더 높은 효율을 보인다.
8. 개발자에서 유저로 페르소나의 변경
   • 테스트 코드를 많이 사용할수록 좀 더 비판적인 시각에서 제품을 바라보기에 유저의 입장에서 바라볼 수 있고 이러한 측면을 통해서 더 나은 UX를 제공할 수 있다.

 

클린 아키텍처 클린 코드와 같은 부분은 모두가 당연히 신경쓰지만 테스트코드는 엑스트라처럼 느껴지는 부분이 있다. 하지만 이러한 테스트 코드를 잘 활용할 수 있다면 내 코드에 대해 장인 정신을 발휘할 수 있는 개발자가 될 수 있다.

 

 

🔶 토스에서 사용하는 테스트 코드와 사용하지 않늩 테스트 코드

---

🎈토스의 기준

대게 테스트 코드는 유닛테스트에서 많이 사용될 것이라고 생각을 하는데 토스에서는 통합 테스트에서 많이 활용은 한다. 이는 사용자 레벨에서 어떤 의미가 있는지를 먼저 생각하고 이와 관련된 동작들을 테스트하기에 사용자 중심적인 관점에서는 유닛테스트보다 통합테스트에 많이 사용하게 된다고 한다.

• 사용하는 경우
  • 퍼널 테스트와 같이 사용자에게 복잡한 값을 입력받거나, 단계로 나누어 입력을 받는 흐름인 경우
  • 의존성이 있는 코드
  • 테스트 케이스가 복잡하고 개수가 많으며 환경이 복잡하고 어려워 피드백 사이클이 긴 경우

 

• 사용하지 않는 경우
  • 유효성이 낮고 너무 손쉬운 테스트인 경우
  • 화면에 그려지는 렌더링을 확인하는 경우 (HMR로 확인이 더 낫다)

 

 

---

 

 

🔶 테스트 코드의 종류

---

테스트 피라미드 (Kent.C Dodds)

🎈Static Test (정적 테스트)

• 코드를 실행시키지 않고 테스트를 실행하는 것을 말한다.
• 대표적으로 Typescript를 통한 컴파일 단계에서의 에러 감지와 ESlint를 활용한 Referrence Error이다.

 

🎈Unit Test (단위 테스트)

• 각 모듈을 단독 실행 환경에서 독립적으로 테스트하는 것을 말한다.
• 대표적으로 Jest와 Testing Library를 통해서 실행할 수 있으며, 단위 테스트의 경우 TDD를 통해서 요구사항에 대해 만족하는지 여부를 확인하는 모듈인지를 확인할 때 많이 사용된다.

 

🎈Integration Test (통합 테스트)

• 두 개 이상의 모듈이 실제로 연결된 상태를 테스트하는 것으로 모듈 간의 연결에서 발생할 수 있는 에러를 검증하는 테스트를 말한다.
• 대표적으로 Jest와 Testing Library를 통해서 실행할 수 있으며, API를 통해서 받아온 데이터가 올바르게 UI 랜더링 되는지 여부 등 2개 이상의 모듈에 대한 통합적인 테스트를 진행한다.
• 주로 MSW와 같은 모킹 서버도 함께 연동하여 사용된다. 

 

🎈End to End Test (E2E 테스트)

• 사용자 입장에서 전체적인 시나리오를 구성해서 서비스를 처음부터 끝까지 이용하는 것을 모두 테스트한다.
• 대표적으로 Cypress, Puppeteer가 있으며 브라우저를 띄워 진행하기에 실행 속도가 느리고 여러 요인으로 인해 테스트가 실패할 수 있어 신뢰도가 상대적으로 낮다.

 

 

---

 

 

🔶 나의 챌린지

D'art라는 프로젝트를 끝내고 나서 테스트에 대해서 적용해 본 내용이 주로 QA를 통한 내용이기에 자동화 테스트를 구현을 해보고 어떤 경우에 테스트를 사용하는 것이 효율적인지 또한 문서로써의 기능을 얼마나 수행할 수 있는지를 확인해보려고 한다.

 

 

 

 

 

[ 출처 ]: https://toss.tech/article/firesidechat_frontend_3

모닥불 | EP.3 프론트엔드 개발에서 테스트 자동화, 꼭 해야 할까?

 

[ 테스트 코드란? ]: https://gnae16.tistory.com/230

[CS Study] 프론트엔드 테스트 코드란?