프론트엔드 테스트 종류

📌 프론트엔드 테스트 종류

우리는 언제 어떤 테스트를 해야 하는가?

📌 테스트란?

프로그램을 실행하여 오류와 결함을 검출한다.
애플리케이션이 요구사항에 맞게 동작하는지 검증하는 절차를 말한다.

📌 테스트의 목적은?

발생 가능한 결함을 예방한다.
애플리케이션이 요구사항을 충족하는지 검증한다.
변경사항들로 인해 새로운 결함이 유입되지 않았는지 확인한다.

📌 테스트의 효과

테스트를 잘 한 사람은 결함에 대한 걱정을 덜 수 있다.

나의 경험으로 볼 수 있는 효과

결론부터 말하자면 가장 큰 효과는 자신감과 빠른 피드백이라 생각한다. 여기서 자신감이 없으면 기존 버그를 수정하거나 새로운 기능을 추가하거나 리팩토링에 대한 부담이 있을 수 있다. 이전에 교내 챗봇 서비스를 개발했던 경험이 있다. 오픈 후, 홍보와 동시에 사람들이 몰린 경험이 있다. 처음부터 만드는 것은 어렵지 않았지만, 점점 리팩토링이나 새로운 기능을 추가하는 부담감이 생기기 시작했다. 테스트 챗봇을 만든 뒤에 눈으로 보는 테스트를 진행했지만, 결과는 마찬가지였다. 그러나 테스트 코드를 작성한 뒤로는 나에게 자신감을 주기 시작했다. 과감하게 리팩토링을 시도할 수 있었고, 기능을 추가할 수 있었다. 왜냐하면 테스트가 깨지는지 돌려보면 되기 떄문이다. 테스트 코드에 대한 효과는 자신감 뿐만 아니라 빠른 피드백을 받을 수 있는 효과도 있었다. 이전에는 테스트 챗봇을 직접 눌러보며 눈으로 테스트하는 과정이 꽤 많은 시간이 걸렸다. 하지만 테스트 코드는 매우 빠른 피드백을 줄 수 있었다. 이로 인해 많은 시간을 아낄 수 있었고, 이렇게 얻은 시간으로 새로운 기능을 추가하거나 수정할 수 있었다.

📌 프론트 테스팅 용어

Static 테스트

코드를 실행시키지 않고 테스트
구문 오류, 나쁜 코드 스타일 등 검증
ex) Eslint, Typescript

Unit 테스트

작은 단위를 떼어 분리된 환경에서 테스트
복잡한 알고리즘이 제대로 동작하는지 확인
Mocking이 필요
ex) Jest

Integration 테스트

애플리케이션 여러 부분들이 통합되어 제대로 상호작용 되는지 테스트
주로 큰 범위(페이지)의 테스트를 의미한다.
모든 기능이 제대로 동작하는 확신을 줄 수 있다.
가장 비중이 크다.
ex) Jest, RTL, Enzyme

E2E(End to End) 테스트

실제 사용자가 사용하는 같은 조건에서 전체 시스템을 테스트
API 서버, DB 등 외부 서비스들을 모두 사용해서 통합된 시스템을 테스트
백엔드 시스템을 Mocking하여 UI 테스트를 진행하기도 한다.
비용이 많이들고, 속도가 느리다.
ex) Cypress, Selenium\

📌 프론트엔드 테스팅 대상

사용자 이벤트(입력) 처리

자바스크립트 API 사용
cypress 도구를 사용해서 브라우저 환경에서 테스트 할 수 있다.
E2E 도구를 사용

서버와의 통신

실제 API 서버를 사용하는 방식
통신 모듈을 Mocking / API 서버를 Mocking 하는 방식
React 에서 Jest 를 권장하고 있다.

시간적 요소

시각적인 부분을 코드로 검증해야 한다.
스냅샷 테스트는 HTML 구조가 의도한 대로 나타나는지를 테스트를 한다. ex) Jest, StoryBook
시각적 회귀 테스는 HTML에 CSS를 더해서 컴포넌트가 실제로 브라우저에서 렌더링이 의도한 대로 나타나는지를 테스트한다. ex) StoryBook

📌 테스트 환경

브라우저

네트워크 IO, 렌더링 엔진 활용 가능
테스트 코드를 다양한 운영체제나 브라우저 사용이 가능하다. (기기 호환성 체크 가능)
Node.js 비해 무겁다.
초기 구동속도가 늦다.
브라우저를 사용하기 위해 별도 설치가 필요 -> Headless 브라우저로 사용하는 것을 권장
ex) Karma, Selenium, Cypress

Node.js 환경

설치 & 실행이 간단하고 속도가 빠르다.
모듈 단위로 테스트가 가능하다.
DOM, BOM API가 없다. -> jsdom을 사용할 수 있으나, 브라우저 동작을 100% 구현하지 못한다.
ex) Jest, Mocha

어떤 환경에서 사용해야 할까?

1. 크로스 브라우징 테스트가 반드시 필요한 경우 브라우저 환경을 사용하자.
2. 브라우저 실제 동작에 대한 테스트가 필요한 경우 브라우저 환경을 사용하자.
3. 그 외의 경우 Node.js 환경을 사용하자.

어떤 것을 고려해야 할까?

100% 정답은 없기에 아래 요소들을 고려하고, 나만의 기준을 만드는 것이 중요하다.
1.
애플리케이션의 종류
비주얼 요소가 중요한가? ex) 차트
모든 브라우저에서 테스트해야 하는가? ex) 에디터
2.
애플리케이션의 규모 및 복잡성
간단한 라이브러리
복잡한 라이브러리
복잡한 웹 서비스
3.
팀 구성
별도 QA팀이 있는가?
서버-클라이언트를 모두 통제할 수 있는가?

📌 참고 자료

TOP