https://www.yes24.com/product/goods/127005970

1. 테스트 범위와 목적

1.1 테스트 범위

1. 라이브러리가 제공하는 함수
2. 로직을 담당하는 함수
3. UI 관련 함수
4. 웹 API 클라이언트
5. API 서버
6. 데이터베이스 서버

테스트를 작성할 때는 어디부터 어디까지 커버하는 테스트인지 주의해야 한다.

1. 정적 분석

타입스크립트나 ESLint가 제공하는 기능을 활용한다.

• 각 모듈 내부의 검증뿐만 아니라 2~3 검증, 3~4 검증처럼 인접 모듈을 연계해 사용할 때의 문제점도 검증한다.

2. 단위 테스트

한 가지 모듈에 한정하여 해당 모듈이 제공하는 기능을 검증하는 테스트.

• 실제로 애플리케이션을 사용할 때는 거의 발생하지 않는 케이스(코너 케이스) 검증에 적합

3. 통합 테스트

1~4, 2~3처럼 모듈 조합으로 제공되는 기능을 검증하는 테스트다.

• 상대적으로 대략적인 검증

4. E2E 테스트

1~4를 통틀어 헤드리스 브라우저와 UI 자동화 도구를 결합하여 검증하는 테스트.

• 실제로 애플리케이션을 사용할 때와 가장 유사한 테스트

1.2 테스트 목적

1. 기능 테스트(인터렉션 테스트)

: 개발된 기능에 문제가 없는지 검증하는 테스트

• 대부분 기능은 UI 컴포넌트 조작에서 시작하기 때문에 인터렉션 테스트가 기능 테스트가 될 때가 많음

2. 비기능 테스트(접근성 테스트)

: 신체적, 정신적 특성에 따른 차이 없이 동등하게 제품을 사용할 수 있는지 검증하는 테스트

3. 회귀 테스트

특정 시점을 기준으로 전후 차이를 비교하여 문제가 있는지 검증하는 테스트

• 시각적으로 보이는 UI 컴포넌트를 개발하기 때문에 시각적 회귀 테스트가 중요하다.

2. 프런트엔드 테스트 범위

2.1 정적 분석

타입스크립트를 활용하는 정적 분석은 버그를 조기에 발견할 수 있도록 한다.

• 타입 추론은 런타입 작동을 예측해주기 때문에 아주 유용하다.
• 함수의 반환 값이 생각한 타입과 일치하는지 검증할 때도 도움이 된다.
• 코드 가이드라인을 제공하는 ESLint도 정적 분석 도구 중 하나다. ESLint는 부적절한 구문을 수정해서 잠재적으로 발생할 수 있는 버그를 사전에 방지한다.

2.2 단위 테스트

단위 테스트(유닛 테스트)는 가장 기초적인 테스트.

테스트할 모듈이 특정 입력값을 받아 기대하는 출력값을 반환하는지 테스트한다.

• ‘이런 상황은 일어날 수 없을까? 일어날 수 있다면 어떻게 처리해야 하는가’와 같은 거듭된 검토 과정에서 미처 고려하지 못했던 부분을 발견할 수 있다.

2.3 통합 테스트

통합 테스트(인티그레이션 테스트)는 여러 모듈을 연동한 기능을 테스트.

커다란 UI 컴포넌트는 여러 모듈을 조합해 기능을 제공하며, 기능은 주로 인터렉션에서 시작한다.

2.4 E2E 테스트

E2E 테스트(엔드 투 엔드 테스트)는 UI 테스트뿐만 아니라 외부 스토리지와 같이 연동 중인 하위 시스템을 포함하는 테스트다.

입력 내용에 따라 저장된 값이 갱신되기 때문에 UI는 몰론 연동된 외부 기능이 정상적으로 작동한는지 검증할 수 있다.

3. 프런트엔드 테스트의 목적

3.1 기능 테스트(인터렉션 테스트)

웹 프런트엔드의 주요 개발 대상은 사용자가 조작할 UI 컴포넌트다. UI 컴포넌트는 사용자가 조작하면 상태를 변경하고, 사용자가 원하는 정보를 제공하기 위해 화면을 갱신한다.

웹 프런트엔드의 기능 테스트는 인터렉션 테스트가 대부분이다.

• 리액트 같은 라이브러리로 구현된 UI 컴포넌트에는 브라우저 없이도 테스트할 수 있는 가상 브라우저 환경이 있다.

3.2 비기능 테스트(접근성 테스트)

접근성 테스트는 비기능 테스트의 한 종류다.

접근성 테스트 실제 사례

• 체크 박스를 체크할 수 있다.
• 오류 응답을 받았을 때 오류 문구를 렌더링한다.
• 렌더링된 화면에 접근성 위반 사례가 있는지 확인한다.

3.3 시각적 회귀 테스트

CSS는 UI 컴포넌트에 정의된 스타일뿐만 아니라 브라우저에 적용된 모든 스타일의 영향을 받는다.

회귀 테스트 중 하나인 시각적 회귀 테스트에서는 헤드리스 브라우저에 그려진 내용을 캡처하여 갭처된 이미지 간 차이를 검증한다. 초기에 렌더링된 상태만 캡처하여 비교하는 것에 그치지 않고 사용자 조작으로 변경된 화면까지 캡처하여 비교한다.

4. 테스트 전략 모델

비용은 개발팀에 큰 영향을 미치기 때문에 충분한 논의를 해야한다. 테스트 계층 간 비용 분배는 테스트 전략을 세울 때 가장 중요한 검토 사항이다.

4.1 아이스크림 콘과 테스트 피라미드

상층부 테스트의 비중이 높은 아이스크림 콘은 안티패턴으로 자주 언급되는 테스트 전략 모델이다.

• 운용 비용이 높음
• 외부 모듈의 의존성

⇒ 불안정한 테스트.

만약 모든 테스트가 통과된느데 수십 분 이상이 걸린다면 개발 흐름에 나쁜 영향을 주게 된다. 그러나 실행 시간을 줄이려고 실행 빈도를 줄이면 테스트 자동화의 신뢰성은 낮아진다.

테스트 피라미드는 마이크 콘의 저서인 “경험과 사례로 풀어낸 성공하는 애자일”에서 등장하는 테스트 전략 모델이다. 하층부 테스트의 비중이 높을수록 안정적이고 가성비 높은 테스트가 가능하다는 것이 핵심이다.

브라우저를 포함하는 상층부 테스트는 실행 시간이 길어서 신속성이 떨어진다. 반면 하층부 테스트는 실행 시간이 짧아 신속성이 높고, 자주 실행할 수 있어서 안정성도 높다. 프런트엔드 테스트 자동화에도 테스트 피라미드가 우수한 전략이라는 의견이 지배적이다.

4.2 테스팅 트로피

테스팅 트로피는 이 책에서 중점적으로 다루는 테스팅 라이브러리를 개발한 켄트 도즈가 만든 테스트 전략 모델.

프런트엔드 갭라에서 단일 UI 컴포넌트로 구현되는 기능은 거의 없다.

테스트 트로피에는 사용자 조작을 기점으로 한 통합 테스트 비중이 높을수록 더욱 우수한 테스트 전략이라는 의도가 있다. 테스팅 라이브러리와 제스트를 사용하면 헤드리스 브라우저 없이도 사용자 조작을 재현해 테스트 할 수 있어서 실행 속도가 빠르면서 실제 제품과 유사한 테스트가 가능하다.

5. 테스트 전략 계획

테스트 전략 모델을 참고해 프로젝트에 최적인 전략을 수립하려면 테스트 대상 및 목적에 따른 판단 기준을 정립해야 한다.

5.1 테스트가 없어 리팩터링이 불안한 경우

• 릴리스된 기능을 목록으로 정리
• 정리 후, 변경 전후로 결함이 발생하지 않았는지 검증하는 회귀 테스트 작성
• 작성 후, 리팩터링 시작

웹 API 서버에 대한 의존성이 깔끔하게 분리되지 않으면 테스트 작성이 어렵다.

• 이때 목 서버를 활용하여 통합 테스트를 실시한다.
  • 목 서버를 활용하면 구현 코드를 수정하지 않아도 테스트할 수 있어 리팩터링 시작 전에 테스트를 작성하고 싶은 개발자들에게 유용하다.
  • 특히, 릴리스된 프로젝트에서 효과적이다.

통합 테스트가 늘어날수록 안심하고 리팩터링 할 수 있는 기능도 많아진다. 점진적으로 테스트를 늘리면서 리팩터링을 실시하면 더욱 안정된 테스트 피라미드 모델을 만들 수 있다.

5.2 반응형으로 제작된 프로젝트

반응형 웹은 하나의 HTML에서 여러 형태의 화면을 제공

• 반응형 웹은 테스팅 라이브러리만으로 스타일을 포함한 세밀한 테스트가 어려움
• 반응형처럼 디바이스 간 서로 다른 스타일을 제공하는 경우, CSS가 적용된 렌더링 결과를 검증할 브라우저 테스트가 필요
  • 이런 상황에서 실시하는 테스트가 브라우저를 사용한 시각적 회귀 테스트.
  • 스토리북은 UI 컴포넌트 단위로 시각적 회귀 테스트가 가능하다.

5.3 데이터베이스를 포함한 E2E 테스트가 필요한 경우

목 서버가 아닌 실제 웹 API 서버를 사용해서 E2E 테스트를 하고 싶다면 테스트용 스테이징 환경을 사용해야 한다.

• 스테이징 환경: 실제로 배포할 환경에 가까운 형태로 만든 테스트용 환경.
• E2E 테스트는 테스트 엔지니어가 프로젝트를 릴리스하기 전에 테스트 계획서를 보면서 수동으로 하는 경우가 많고, 브라우저를 사용한 UI 자동화 방식으로 테스트하는 경우도 있다.

스테이징 환경을 만들지 않고도 실시할 수 있는 테스트 자동화 방법도 있다.

• 테스트 할 시스템을 컨테이너화해 CI 환경에서 실행한 후 연동 중인 여러 시스템과 함께 테스트하는 것이다.
  • 비교적 환경 구축 비용이 적고 개발자 혼자서도 구축할 수 있는 장점이 있다.

Column: 테스트를 너무 많이 작성하는 것은 아닌지 되돌아보자

• 지나치게 많이 작성한 테스트를 발견했다면 과감하게 줄여야 한다.
• 프로젝트에 알맞은 기술 구성은 무엇이며, 어떤 테스트 전략이 프로젝트 적합한지 항상 되돌아보자.