[도서] 프런트엔드 개발자를 위한 테스트 가이드

728x90

다른 책 읽으려고 도서관에 갔다가 우연히 발견하고 제목이 눈길을 끌어 그 자리에서 정독하고 온 책이다.

사실 나도 요즘 테스트 자동화에 대해 관심이 있었는데, 책 덕분에 시야가 넓어진 것 같다.

기억하고 싶은 부분들을 핸드폰으로 적어왔고, 책의 내용에 개인적으로 공부한 내용을 추가해서 기록해본다.

웹 애플리케이션을 위한 테스트 유형

웹 애플리케이션 테스트는 크게 목적과 범위에 따라 나눌 수 있다.

목적으로 분류하면 → 기능성/비기능성 테스트로 나뉘고
범위로 분류하면 → 코드의 크기에 따라 단위 테스트, 통합 테스트, UI 테스트, E2E 테스트 등 4단계로 나눌 수 있다.

1. 테스트 목적에 따른 분류: 기능성 vs 비기능성

CI에 모든 유형의 테스트를 포함시키느냐가 성과가 높은 애자일 팀과 그렇지 못한 팀의 차이를 만든다.
그리고 이 테스트 유형에는 코드가 변경될 때마다 자동으로 실시되는 기능성, 비기능성 테스트가 포함되어야 한다.
(책 내용 중 일부 발췌)

1) 기능성 테스트

웹 사이트의 모든 링크가 제대로 동작하는가 (내비게이션, 소셜미디어, 메일 등)
폼과 연계된 페이지 테스트
- 필드 긍정/부정 값 입력
- 필수입력 필드 검증
- 모든 플랫폼에서 폼 전송 여부
쿠키 정책 → 캐시가 정리되면 쿠키도 삭제되어야 한다
웹사이트 내의 전체 플로우를 비즈니스 흐름 관점에서 테스트
- 모든 내부 링크와 플로우가 동작하는가
- UI와 레이아웃
- 모든 화면 크기와 해상도를 고려한 호환성 확인
- UX 및 지역화

2) 비기능성 테스트 (품질/인프라)

성능 및 부하 테스트:
- 응답시간이 목표한 범위에 있는지 → 접속에 3~5초 이상 걸리면 안 된다.
- 피크일 때(수백만 명의 가상 사용자) 정상적으로 부하를 처리할 수 있는지
- 부하를 피크 타임까지 끌어올렸을 때 어느 정도까지 애플리케이션이 견딜 수 있는지 (스트레스 테스트)
- 웹사이트 가용성에 문제가 있을 때 어떻게 복구되는지
접근성 테스트:
- 일반적인 웹 접근성 규칙을 적용하고 있는지
- 여러 플랫폼과 언어에서 테스트 (웹, 모바일 모두)
- 테스트 자동화를 위해 접근성 ID(웹 요소)가 적절하게 부여됐는지
보안 테스트:
- 권한 및 인증에 따른 다운로드 가능 여부
- 비활성 세션 자동 종료 여부
- SSL 인증서를 사용해서 암호화된 SSL 페이지로 리다이렉트 하는지 등

보안 테스트는 2가지로 나눌 수 있다.

1. 정적 보안 테스트 (Static Application Security Testing, SAST) = 화이트박스 테스트
코드를 실행하지 않고, 소스 코드 자체를 살펴보며 취약점을 찾는 방법
- 시점: 개발 단계(코드 작성이나 빌드 시점)에서 바로 실행
- 목적: 소스코드 레벨에서 발생 가능한 보안 이슈나 취약한 라이브러리 사용을 잡아내는게 목적

2. 동적 보안 테스트 (Dynamic Application Security Testing, DAST) = 블랙박스 테스트
실제 앱을 실행시켜두고, 외부에서 해커처럼 공격해보며 취약점을 찾는 방법
- 시점: 배포 완료되어 서비스가 실제로 구동중인 환경(테스트 서버)에서 실행
- 목적: 실제 살아 움직이는 앱에서만 발생하는 외부 보안 이슈를 찾아낸다.

2. 테스트 범위에 따른 분류: 4단계 테스트

앞서 기능성/비기능성으로 분류된게 "무엇을 검증할 것인가"를 기준으로 나눠졌다면,
범위에 따른 4단계 분류는 "어느 크기로 검증할 것인가"를 기준으로 한다.
가장 작은 코드 조각부터 실제 유저가 사용하는 전체 화면까지 점진적으로 확대된다.

1) 단위 테스트 (Unit Test)

"가장 작은 코드 조각이 독립적으로 정확히 작동하는가?"
네트워크나 DB와 같은 외부 환경을 완전히 배제하고, 순수 JS/TS 로직이 정확한 정답을 출력하는지 검증한다.
대표 툴: Jest, Vitest, Mocha, Jasmine

2) 통합 테스트 (Integration Test)

"다수의 컴포넌트나 모듈들이 서로 묶였을 때도 올바르게 상호작용하는가?"
컴포넌트나 모듈이 합쳐졌을 때, 데이터가 유기적으로 잘 흐르는지를 검증한다.
브라우저를 직접 띄우지는 않지만 메모리 상에 가상 DOM을 그려서 확인한다.
대표 툴: Jest + React Testing Library, Vitest

3) UI 테스트

"실제 유저에게 보여지는 화면(디자인, 레이아웃)이 깨지지 않았는가?"
CSS나 폰트 등 UI가 오작동 없이 가이드대로 예쁘게 그려지는지를 픽셀 단위로 대조하여 검증한다.
대표 툴: Storybook, Percy, Happo

4) E2E (end-to-end) 테스트

"유저가 처음부터 끝까지 서비스를 이용하는 시나리오가 완벽한가?"
100% 실제 사용자 관점의 테스트.
테스트 코드가 가상 브라우저를 직접 조작하며 전체 비즈니스 시나리오에 이슈가 없는지 확인한다.
대표 툴: Cypress, Playwright, Puppeteer

E2E 테스트의 구동방식

1. 헤드 방식 (Headed)

실제 사용자가 보는 화면을 그대로 띄워놓고 테스트하는 방식.

GUI가 나타나고, 테스트 코드를 통해 마우스 커서나 터치 조작이 자동으로 실행되는걸 볼 수 있다.

장점	- 테스트가 어느 단계에서 실패했는지 시각적 디버깅이 쉽다. - 실제 유저 환경과 동일하여 레이아웃 오류나 디자인 에러를 찾기 좋다.
단점	- 렌더링 과정이 포함되어 테스트 수행 속도가 상대적으로 느리다. - 컴퓨터의 CPU와 메모리를 많이 차지한다.

2. 헤드리스 방식 (Headless)

화면을 모니터에 출력하지 않고, 메모리 상에서만 브라우저나 앱의 기능을 구동하여 테스트하는 방식.

내부적으로 코드들이 모두 실행되고 있으며 테스트 결과(성공/실패)만 로그나 리포트로 출력된다.

장점	- 렌더링 과정이 생략되어 테스트 속도가 헤드 방식에 비해 월등히 빠르다. - 자원을 효율적으로 사용하여 다수의 테스트를 동시에 돌리기 유리하다. - 모니터가 없는 리눅스 서버(CLI 환경)에서도 테스트 코드를 돌릴 수 있다.
단점	- 오류가 났을때 스크린샷 저장 기능이나 로그 파일에 의존해야해서 디버깅이 어렵다. - 화면을 띄우지 않기 때문에, 시각적 오류는 감지하기 어렵다.

웹 애플리케이션 테스트 자동화 프레임워크

아키텍처 기반으로 나누자면 3가지로 분류할 수 있다.

브라우저 내장 JS 테스트 기반: Cypress
→ 테스트 코드가 실제 웹사이트 코드와 동일한 브라우저 내부에서 직접 실행된다.
크롬 개발자도구 프로토콜 기반: Playwright, Puppeteer
→ 크롬 개발자도구 프로토콜(CDP)을 이용해 브라우저를 외부에서 원격 제어하는 방식.
브라우저 속도 자체를 100% 활용한다.
웹 드라이버 프로토콜 프레임워크: Selenium
→ 브라우저 종류별로 전용 드라이버 프로그램을 두고 명령을 전달한다.
모든 브라우저를 지원하지만 중간 단계를 거치기 때문에 상대적으로 무거운 편이다.

여기까지 읽고, 요즘 테스트 자동화 프레임워크는 어떤걸 많이 쓰는지 체크해봤더니 playwright가 압도적으로 높았다. 프론트엔드 개발자 구인공고에 Cypress가 제법 보이길래 공부해볼까 생각했었는데 의외였다.😅

https://npmtrends.com/cypress-vs-playwright-vs-puppeteer-vs-selenium-webdriver

프레임워크마다 특징이나 장단점이 다르기 때문에, 서비스에 맞는 프레임워크를 선택하는게 중요할 것 같다.

코드 커버리지 vs 테스트 커버리지

커버리지(Coverage)는 개발자가 구축한 테스트 환경이 얼마나 꼼꼼하게 제품을 검증하고 있는지 측정하는 지표이다. 무엇을 기준으로 삼느냐에 따라, 테스트 커버리지와 코드 커버리지로 나눌 수 있다.

1. 테스트 커버리지 (Test Coverage)

"기획서/요구사항에 얼마나 부합하며, 얼마나 꼼꼼하게 검증했는가?"

모든 테스트 유형을 사용해서 요구사항을 얼만큼 만족하는지 보여주는, 테스트 전반에 대한 지표.

브라우저 종류, OS 종류 등 얼마나 다양하게 지원하는지 플랫폼의 범위도 포함한다.

테스트 커버리지에 포함되는 세부 항목은 아래와 같다.

제품 기능 커버리지:
애플리케이션이 모든 플로우와 웹사이트 화면, 내비게이션 이동을 얼마나 잘 처리하고 있는지 확인한다.
품질 관점에서 어떤 식으로 동작하는지도 확인한다.
제품 요구사항 커버리지:
계획된 모든 사용자 스토리와 기능을 구현했는지 확인한다.
모든 기능을 테스트했다는 것이 해당 버전에 포함돼야 할 모든 기능이 구현됐다는 것을 의미하지는 않는다.
호환성 커버리지:
모든 테스트 유형이 얼마나 많은 플랫폼에서 테스트되는지,
다양한 OS 버전을 비롯해 얼마나 많은 웹/모바일 플랫폼을 지원하는지 확인한다.
위험 커버리지:
예를 들어, 의존성과 문제가 있는 경우 보완 계획이 있는지를 확인한다.
경우에 따라서는 이 유형의 지표가 다른 지표보다 영향력이 클 수 있다.

2. 코드 커버리지 (Code Coverage)

"얼마나 많은 코드가 여러 유형의 테스트에 의해 실행되고 확인됐는가?"

코드 커버리지 관점에서, 단위 테스트가 가장 우선순위가 높은 테스트 유형이다.

일반적으로 코드 커버리지 보고서에서는 아래 정보들을 제공한다.

분기 커버리지:
의사 결정 프로세스 과정에서 발생할 수 있는 모든 가능성, 즉 처리에 대한 분기를 테스트했는지 확인한다.
예를 들어, 사용자 입력에 따라 달라지는 모든 분기 처리를 테스트해야 한다.
함수 커버리지: 코드 내의 모든 함수를 테스트했는지 확인한다.
실행 구문 커버리지: 코드 내의 모든 실행 가능한 구문이 적어도 한 번은 실행됐는지 확인한다.
반복 커버리지: 코드 내의 반복문이 적어도 한 번은 실행됐는지 확인한다.

💡 커버리지 측정의 본질과 보장 범위
- 코드 커버리지는 제대로 측정하려면 개발자가 측정 코드를 테스트 과정에 추가해야한다.
- 코드 커버리지는 애플리케이션의 런타임 시점에 코드 수준의 여러 시나리오를 모두 확인했으며, 대부분의 코드를 테스트했다는 것을 보장해야 한다.
- 테스트 커버리지는 애플리케이션의 전체적인 품질 확인을 위한 것으로 UX, 보안, 접근성 등을 포함한다.

코드를 짜는 것만큼 내가 짠 코드를 책임감 있게 검증하는 과정도 개발자의 필수 역량이지만, 사실 그동안 실무에서 테스트 코드를 직접 작성해 본 적은 없었다. 로컬부터 스테이징, 운영 단계에 이르기까지 늘 사람이 직접 검사하는 '수동 테스트' 워크플로우로 일해왔기에, 머리 한편에 항상 테스트 자동화와 CI/CD 툴에 대한 갈증과 궁금증이 남아있었다. 이번에 도서관에서 우연히 읽은 책 덕분에 막연하게만 느껴졌던 테스트 자동화의 전체적인 지도를 머릿속에 깔끔하게 그려볼 수 있었다.👍

올해 초 퇴사하고 개인 프로젝트를 리뉴얼하면서 GitHub Actions를 처음 도입해봤는데, 여기에 오늘 정리한 웹 테스트 이론까지 더해지니 CI/CD 자동화의 장점이 훨씬 더 크게 와닿는다. 지금 작업 중인 개인 프로젝트 리뉴얼 과정에도 자동화 테스트 환경을 하나씩 직접 구축해볼까 싶다. 물론 맹목적으로 테스트 자동화를 도입하기보다, 프로젝트의 규모와 팀의 상황에 맞게 현명한 전략을 짜는 것이 먼저일 것이다.

앞으로 개발을 해나가면서 유저가 마주할 핵심 UX와 기능적 안정성을 빈틈없이 방어하려면 어떤 테스트가 가장 적절할지, 끊임없이 고민하는 책임감 있는 개발자가 되고 싶다.🙏