기초부터 완성까지 프론트엔드 - day7

Day 7

오늘 읽은 범위

• 13장 프론트엔드 테스트
• 14장 스냅숏 테스트와 시각적 테스트

책에서 기억하고 싶은 내용을 써보세요.

프론트엔드 테스트

내부 코드의 다양한 연산뿐만 아니라 클라이언트 영역에 대한 사용자의 인터랙션도 고려하여 올바른 결과가 나오는지 검증해야 함

사용자 관점에서 최대한 사용자가 직접 사용하는 것처럼 시나리오를 작성하여 검증하는 것이 중요함

• DOM 요소들의 레이아웃이나 스타일이 적잘하게 적용되었는지,
• 애니메이션이 있다면 애니메이션이 올바르게 동작하는지,
• 등등…

좋은 테스트란?

• 모든 테스트는 독립적으로 실행되어야 한다
• 테스트 결과는 일관성이 있어야 한다
• 내부 구현에 종속된 테스트는 지양해야 한다
• 테스트는 단순하고 이해하기 쉬워야 한다
• 유지 보수가 가능한 테스트를 작성해야 한다

TDD (Test Drive Development)

테스트 주도의 개발
개발 코드를 작성하기 전에 깨지는 테스트 코드를 먼저 작성하고, 지속적인 리팩토링을 통해 테스트가 검증되는 과정을 반복하며 개발

■ TDD 사이클
적색 (테스트 작성) → 녹색 (테스트 통과) → 리팩토링 → 과정 반복

단위 테스트

• 가장 기본적인 단위
• 다른 요소와의 상호작용을 검증하기보다는 각 요소의 동작을 독립적으로 검증하는 테스트
• 요소 내 모든 행위나 상태를 검증하기 보다는 핵심 코드만 검증하는 것이 좋음
• 핵심코드: 외부에 인터페이스로 노출되는 코드 또는 중요한 연산을 처리하는 코드

통합 테스트

• 일부 개별 요소들이 조합되었을 때 올바르게 동작하는지 확인
• 테스트의 사전 환경 설정이 복잡할 수 있고, 모킹이 필요할 수 있음

E2E 테스트 (End to End)

• 실제 애플리케이션을 실행하여 전체 워크 플로우를 검증하는 테스트
• 실제 사용자가 사용하는 것처럼 시나리오를 작성하여 검증
• 설정과정이나 테스트 실행 시간이 가장 오래 걸리는 테스트

jest

• 검증에 필요한 매치(matcher)와 모킹에 필요한 API들을 대부분 제공하기 때문에 별도의 라이브러리를 결합하지 않고도 쉽게 테스트를 작성할 수 있음
• 단위 테스트나 통합테스트를 작성할 때 가장 많이 사용하는 프레임워크

테스트 더블

• 테스트 코드와 외부 의존성 모듈을 분리할 수 있음
• API 또는 인터페이스에 접근하는 것이 아니라 별도의 테스트 더블 모듈 또는 객체에서 데이터를 가져오기 때문에 테스트 속도가 개선됨
• 다양한 데이터나 예외 처리에 대한 상황을 쉽게 재현하여 검증
• 더미(Dummy)
  • 객체가 필요하지만 실제 기능의 실행까지는 필요하지 않은 경우 사용
• 페이크(Fake)
  • 일부 동작을 정해진 결과로 단순화하여 구현한 것
• 스텁(Stub)
  • 더미 객체가 실제로 동작하는 것처럼 만들어 놓은 것
• 스파이 (Spy)
  • 스텁과 유사하지만 구현된 객체가 어떠한 인자와 몇번 호출했는지를 확인할 수 있음
  • 자기 자신의 호출 상황을 기록하기 때문에 이벤트 리스너와 같은 콜백 함수의 호출 여부를 검증할 때 유용
• Mock
  • 실체 객체와 동일한 동작을 하도록 만들어진 모의 객체
  • 큰 비용이 들며, 모의 객체를 남용하면 테스트 코드의 신뢰성을 떨어뜨림

스냅숏 테스트

사용자가 인지하지 못한 UI 구성 요소의 변화를 탐지하기에 매우 유용한 테스트를 의미

■ 스냅숏 작성 방법

1. 구성 요소를 렌더링
2. 렌디링된 결과를 직렬화해 스냅숏과 비교
3. 스냅숏과 같은 경우 테스트가 통과하며 스냅숏이 없을 경우 업데이트 함
4. 스냅숏과 다른 경우 예상했던 DOM의 변경사항인지 확인 후 스냅숏을 업데이트 함
5. 예상했던 변경사항이 아닐 경우 검증이 실패한 것이기 때문에 테스트 코드를 수정해야 함

※ 큰 스냅숏을 작성하지 않는 것이 가장 중요함

■ 장점

• 예상치 못한 변경을 빠르게 알아차릴 수 있음
• DOM 구조뿐만 아니라 직렬화가 되는 모든 데이터를 검증할 수 있음
• 관리하고 있는 객체 상태 변화를 알 수 있음
• API 응답의 json 구조를 검증할 수도 있음

■ 단점

• 어느 범위까지 테스트를 수행하는지 명확한 의도가 드러나지 않음
• 코드 수정 후 처음의 스냅숏과 다른 결과를 갖는다면 왜 다른 스냅숏을 가지게 되었는지 추가 디버깅이 필요
• TDD를 수행하기 적합하지 않음
• 모든 UI의 변화를 감지하고 테스트할 수 없음

시각적 회귀 테스트

변경사항으로 인해 안정적이던 소프트웨어 기능에 문제가 생기거나 수정했던 버그가 다시 발생하는 것을 검출하는 테스트
올바른 위치에 렌더링되던 요소들이 변경 사항에 따라 레이아웃이 틀러지거나 스타일이 달라지는지 반복적으로 확인

■ 장점

• 사람의 눈으로 확인하기 어려운 여러 UI 변경을 쉽게 파악할 수 있음
• 여러 해상도와 브라우저 환경에서 픽셀 단위로 UI를 검증하기 때문에 이러한 변경점을 확인하기 편리함

■ 단점

• 유료 서비스가 많음
• TDD를 적용하기 어려움

■ 스토리 북

• 오픈 소스 UI 개발 도구
• 서버나 외부 환경에서 분리되어 컴포넌트들의 조합이나 특정 UI상황을 스토리로 생성하고 관리하는 것에 도움을 줌
• 공통 컴포넌트에 대한 정보를 동료에게 쉽게 전달할 수 있으며, 각 레이아웃을 이루는 여러 컴포넌트가 적절하게 렌더링되었는지 확인할 수 있음

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

테스트에 대해 공부해야지… 생각만 했었는데 책을 읽으며 간단한 개념에 대해 알 수 있어서 좋았고, 테스트를 하는 방법은 이해가 되지 않았다. 이 부분은 내가 만든 프로젝트에 직접 테스트 코드를 작성해야할 때 다시 한번 학습해야겠다.

개발자 공고들을 보면 스토리북을 사용하여 UI를 개발한 사람을 우대한다는 내용들이 있어 스토리북이 뭐지? 했었는데, 스토리북이 무엇인지, 왜 UI 개발에 효과적인 도구인지 알게되었다.