[10분 테코톡 도비] "프론트엔드에서의 테스트" 리뷰

🔷 내용 정리

🔹테스팅의 장점

테스팅으로 코드에 대한 확신과 안정성을 줄 수 있다.

🔹테스팅 트로피

🔷정적 테스트 : 실행시키지 않고 테스팅

• EsLint, Typescript

🔷단위 테스트 : 기능 단위나 컴포넌트 단위를 따로 떼어내 테스팅

• 의존성이 있는 모듈 같은 경우 Moccking 하여 사용
• 단위가 적어 작성 비용이 낮다, 실행 속도가 빠르다

🔷통합 테스트 : 어플리케이션의 여러 부분을 통합하여 상호작용을 테스트

• 큰 단위로 테스트 (페이지, 큰 규모의 기능)
• jest, RTL 사용

🔷E2E 테스트 : 사용자가 사용하는 조건에서 테스팅

• AWS나 서버 DB 등이 합쳐진 환경에서 테스팅
• 작성이 어렵고 실행 속도가 느리다
• 실행 시나리오가 너무 다양하다
• 100% 신뢰성을 가지기 어렵다
• Cypress 나 셀레니움 등을 사용한다

 

너무 많은 테스트 커버리지는 오히려 시간을 과하게 소모시킬 수 있다. 최대한 통합 테스트 위주로 테스트 할 것 (테스팅 속도와 비용이 가장 균형적인 테스팅)

 

🔷테스팅 예시

1️⃣ 버튼 클릭 이벤트 핸들러 테스트

node.js 환경

testing-library에서 제공하는 fileEvent와 userEvent를 통해 테스팅이 가능하다.

 

브라우저 환경

cypress나 셀레니움을 이용할 수 있다. 실제로 브라우저 상의 요소를 컨트롤 하여 사용자의 이벤트를 직접 컨트롤 할 수 있다.

 

2️⃣ API 테스팅

API 테스팅을 위한 방식은 크게 두가지로 나뉜다. 실제 서버를 구축하거나, 모킹하는 방법이다.

1. 실제 API 서버를 사용하는 방법 : 기존 API 서버가 완성돼 있어야 하므로 보통 통합테스트나 E2E 테스트에서 사용된다.
2. 직접 테스트 API 서버 구축 : 직접 테스트 API 서버를 구축하여 테스트하나 비효율적이다.
3. API Client 모킹하는 방법 : 단위 테스트에서 주로 사용가능하다

API 모킹

• 내가 원하는 응답을 받을 수 있다.
• jest나 testing-library로 사용할 수 있다.
• 예시) Fetch 같은 서버 통신이 필요한 함수가 있을 경우, API 서버가 없으면 테스팅하기 어려우나, jest를 통하여 다음과 같이 간단하게 모킹할 수 있다.

3️⃣시각적 요소 테스팅

• 백엔드는 입력과 출력이 정해져 있어 테스트가 용이하다.
• 프론트엔드의 경우 입력값이 사용자의 액션이고, 출력 값은 사용자의 액션에 따른 화면의 변화이다.
• 그러다 보니 시각적인 요소들이 잘 동작하는지 테스트 해야 할 필요가 있다.

시각적 요소를 테스팅 하는 방법에는 스냅샷 테스트와 시각적 회귀 테스트가 존재한다

• 스냅샷 테스트
  • HTML 구조가 의도한 대로 나타는지를 테스트함
  • ex) jest의 toMatchSnapshot()으로 현재의 HTML의 구조를 저장하여 비교할 수 있음
• 시각적 회귀 테스트
  • HTML에 CSS를 더해 컴포넌트가 실제로 브라우저에서 렌더링 되는 모습이 의도대로 나타는지 테스트 할 수 있다.
  • StoryBook을 사용하여 테스트 가능

 

🔷테스팅 환경

보통 프론트엔드에서의 테스팅은 브라우저 환경 이거나 노드 환경 에서 이루어지는데 각각 장단점을 가진다.

1. 브라우저 환경에서의 테스트
   장점
   • 네트워크IO, 렌더링 엔진 활용 가능
   • 테스트 코드를 다양한 운영체제, 브라우저에서 사용이 가능하다 ⇒ 호환성 체크가 가능하다
   단점
   • Node.js 에 비해 무거워서 초기 구동속도가 늦다
   • 브라우저에서 사용하기 위해 별도로 설치가 필요하다 ⇒ Headless 브라우저로 사용하는 것을 권장
   ex) Karma, Selenium, Cypress
2. 노드 환경에서의 테스트
   장점
   • 설치 및 실행이 간단하고 빠르다
   • 모듈 단위로 테스트가 가능하다
   단점
   • DOM이나 WebAPI를 사용할 수 없다 ⇒ Jest에서 jsdom(가상돔)을 사용하나, 100% 완벽하기 구현하진 못한다.
   ex) Jes, Mocha

 

TOAST UI 팀에서 제시하는 가이드

1. 브라우저들이 표준이 생기고, 서로 호환이 잘 되다 보니 크로스 브라우징이 ’반드시’ 필요한 경우에는 브라우저 환경에서 테스팅 권장
2. 브라우저의 실제 동작에 대한 테스트가 필요한 경우 브라우저 환경을 권장
3. 그 외의 경우 Node.js 테스트 환경을 권장

 

🔷느끼고 배운 것들

1️⃣ TDD 환경의 도입의 필요성

 팀원들과 협업을 해야 하는 프로젝트가 존재하다 보니 미리 해결 해야 할 여러 고민들이 앞섰습니다.

 내가 잘못 짠 코드로 인해서 팀원들이 피해를 보는 상황이나 당장 시간이 급박한데 백엔드 팀원의 API 코드가 만들어지지 않은 상황이 생겼을 경우 어떤식으로 해결을 할까?

 

 또한 규모가 커지는 프로젝트일 수록, 기능 하나를 브라우저상에서 디버깅하는데 조건들이 굉장히 다양해지다보니, 브라우저 디버깅에도 피로도를 느끼고 있었습니다.

 

 이러다 보니 테스팅을 미리 공부해서 도입하기로 생각을 하고 있었습니다. 이번 기회에 많은 걸 배워 추후 프로젝트에 TDD 환경을 도입하려고 합니다.

 

 코드의 안정성을 높여주고, 완성되지 않은 API 대신 모킹을 이용한 테스팅을 도입하여 독립적인 개발 환경을 가지고, 디버깅 대신 테스팅을 통해 개발 속도를 높여 줄 수 있는 TDD 환경의 도입의 필요성을 가지게 됐습니다.

2️⃣내가 해야할 것

다음 프로젝트까지 2주의 시간이 남았는데, 우선 Node 환경을 위해 대표적인 테스팅 라이브러리인 Jest 와 브라우저 환경의 테스팅을 위해 Cypress 를 사용해보고 익힐 예정입니다.

 

 

 

출처

https://www.youtube.com/watch?time_continue=468&v=pkYUcKWOqPs&embeds_referring_euri=https%3A%2F%2Fwww.notion.so%2F&source_ve_path=MTM5MTE3LDI4NjY2&feature=emb_logo