프론트엔드 테스트

 

프론트엔드 테스트에 대한 얕은 개념 파악

목차

1. 프론트엔드 테스트란?

2. 좋은 테스트란?

3. TDD와 Trade off

4. 테스트의 종류

5. 테스트 피라미드

6. jest

 

---

1. 프론트엔드 테스트란?

애플리케이션이 기대한 결과대로 동작하는지 검증하는 일이다.

애플리케이션의 안정성과 유지보수성 향상을 목적으로 하며, 좋은 테스트 작성은 빠르고 효과적으로 피드백을 받아 버그를 검출할 수 있다.

 

프론트엔드는 내부 코드의 연산 뿐만 아니라 클라이언트 영역에서 사용자와의 인터랙션 또한 고려해야한다.

DOM 요소들이 적절한 모양으로 적절한 위치에 배치되어있는 지 등 역시 검증해야한다.

 

 

---

2. 좋은 테스트란?

모든 테스트는 독립적으로 실행되어야 한다.

• A테스트가 B테스트보다 나중에 실행될 경우 검증에 실패한다면, 다른 상황에서 성공하더라도 신뢰할 수 없다.
  각 테스트들은 다른 테스트의 실행 여부와 상관없이 독립적으로 수행되어야 한다.

테스트의 결과는 일관성이 있어야 한다.

• 외부 환경(OS, 네트워크, 타 시스템과의 인터페이스)에 상관없이 일관성 있는 검증을 수행해야한다.
  실제 데이터를 충분히 활용한다면 테스트의 신뢰도를 높일 수 있으며, 외부 인터페이스 처리에 따라 변경될 수 있는 부분은 모킹으로 대체하지 않고 반드시 테스트를 작성해야 한다.

내부 구현에 종속된 테스트는 지양해야 한다.

• 내부 구현에 종속적인 테스트 코드는 작은 구현의 변경에도 깨지기 쉬우며, 유지 보수 비용이 크다.
  따라서 테스트 코드는 내부 구현보다는 인터페이스 기준으로 테스트하는 것이 좋다.

테스트는 단순하고 이해하기 쉬워야 한다.

• 테스트 모드의 가독성이 중요하다. 다른 사람들이 테스트 코드만 보고 어떤 테스트를 하는 것인지 한 눈에 파악할 수 있도록 작성하는 것이 좋다.
  따라서 하나의 테스트에서 너무 많은 테스트를 수행하지 않는 것이 좋으며, 결과 검증 코드가 복잡하다면 별도의 함수로 추상화하여 사용하는 것이 좋다.

유지 보수가 가능한 테스트를 작성해야 한다.

• 애플리케이션 코드가 변경됨에 따라 테스트 코드 역시 관리되어야 한다. 너무 작은 단위의 테스트는 유지 보수를 어렵게 만든다.

 

---

3. TDD와 Trade off

TDD(Test Driven Development)는 테스트 주도의 개발을 의미한다.

실제로 개발 코드를 작성하기 전에 깨지는 테스트 코드를 먼저 작성하고, 지속적인 리팩토링을 통해 테스트가 검증되는 과정을 반복하며 개발하는 방법론이다.

 

1. 적색 : 추가하려는 기능을 개발하기 전에 테스트를 먼저 작성한다. => 테스트 실패로 오류 메시지 표시

2. 녹색 : 코드를 구현하여 테스트를 통과시킨다 => 성공 메시지 표시

3. 리팩토링 : 작성한 코드를 살펴보고 이해하기 쉬우며 잘 설계되었는지 확인

4. 반복

 

TDD 과정 속에서 인터페이스나 각 계층 간의 의존성에 대해 지속적인 리팩토링을 실행하여 깔끔한 코드를 얻을 수 있다.

 

---

4. 테스트의 종류

프론트엔드 테스트의 종류는 크게 단위 테스트, 통합 테스트, E2E 테스트, 시각적 회귀 테스트로 나눌 수 있다.

앞의 세 가지는 애플리케이션의 동작 및 워크 플로우를 검증한다면, 시각적 회귀 테스트는 시각적인 요소들을 비교하여 검증한다.

 

단위 테스트

단위 테스트는 단일 함수의 결과값, 클래스나 컴포넌트의 상태, 행위를 검증한다.

다른 요소와의 상호작용을 검증하기 보다는 각 요소의 동작을 독립적으로 검증하는 테스트이다.

요소 내의 모든 행위/상태를 검증하기 보다는 핵심 코드만 검증하는 것이 좋다.

예를 들어 인터페이스로 노출되는 public한 메서드들에 대해서만 테스트를 작성할 수 있다.

private 메서드 테스트 코드는 너무 많아질 수 있으며 내부 구현 변경에 따라 깨지기 쉽기 때문에 지양하는 것이 좋다.

 

 

통합 테스트

통합 테스트는 개별 요소들이 조합되었을 때 올바르게 동작하는 지 확인한다.

단위 테스트에 비해 테스트의 사전 환경 설정이 복잡할 수 있으며, '모킹'이 필요할 수 있다.

하지만 모킹은 최대한 적게하는 것이 좋다.

 

 

E2E 테스트

E2E는 End-To-End의 줄임말로, 실제 애플리케이션을 실행하여 전체 워크 플로우를 검증하는 테스트이다.

애플리케이션을 실제 사용자가 사용하는 것처럼 시나리오를 작성하여 검증한다.

 

---

5. 테스트 피라미드

각각의 테스트필드에 들어가는 비용이 다르다.

따라서 각 테스트를 작성함으로써 얻을 수 있는 효과와 신뢰성을 따져보고, 어떤 것이 Trade Off를 최소화할 수 있는지 생각해보아야 한다.

 

여러 텍스트 필드를 입력하고 버튼을 클릭하여 내용이 올바르게 전송되는지 확인하고 싶다면,

-> E2E보다는 통합 테스트가 적절할 수 있다.

 

어떤 모듈에 복잡한 계산 로직이 있다면,

-> 단위 테스트에서 해당 연산만 검증하는 것이 적절할 수 있다.

 

 

---

6. jest

jest는 페이스북에서 만든 자바스크립트 테스팅 프레임워크이다.

검증을 실행하는 매처(matcher)와 모킹에 필요한 API들을 대부분 제공하기 때문에 별도의 라이브러리를 결합하지 않고도 쉽게 테스트를 작성할 수 있다.

 

다만 Node.js 환경에서 테스트를 실행하기 때문에 브라우저처럼 DOM에 접근하거나 조작하는 것은 불가능하다.

대신 jest에서 제공하는 jsdom이라는 환경에서 DOM API를 호출하여 검증할 수 있다.

 

 

 

 

참고

기초부터 완성까지, 프런트엔드

기초부터 완성까지, 프런트엔드 | 이재성 | 비제이퍼블릭(BJ퍼블릭) - 예스24