소프트웨어 7원칙등 QA 분야에서 사용되는 원칙이 많이 있습니다만 프론트엔드 환경에서 테스트를 적용하기 위해 개인적으로 학습한 개념과 원칙을 정리했습니다.
테스트의 개념
제품이 예상하는 대로 동작하는지 검증하는 작업
- 제품 ( === 함수, 특정 기능, UI, 성능, API 스펙)
- 예상하는 대로 ( === 요구사항에 맞게)
테스트의 흐름
- Arrange (준비)
- Act (실행)
- Assertion (검증)
테스트 코드 작성 시점
개발과 동시에 진행한다
테스트를 하는 이유
- 나의 코드가 요구사항을 만족하며 정상적으로 동작하는 증거가 된다.
- 이슈에 대한 예측이 가능하여 버그를 빠르게 발견 가능하다.
- 코드 리팩토링시 CI 에 대한 걱정을 하지 않아도 된다.
- 코드의 의존성을 낮출 수 있다.
- 테스트 코드가 일종의 문서화 효과를 가진다.
- 개발 시간을 절약할 수 있다.
테스트 피라미드
테스트의 범위와 비용에 따라 세 가지 주요 유형의 테스트를 계층화한 개념
단위 테스트(Unit Tests)
- 소프트웨어의 가장 작은 단위인 클래스나 함수, 컴포넌트를 독립적으로 테스트한다.
- 각 단위의 기능이 올바르게 동작하는지 확인하는 것이 목적
- 단위 테스트는 개발 단계에서 수행되며, 자동화되어 있어 반복 실행이 용이하다.
통합 테스트(Integration Tests)
- 통합 테스트는 두 개 이상의 단위가 상호작용할 때 올바르게 동작하는지 확인
- 모듈, 컴포넌트, 서비스 등 더 큰 범위의 코드 부분을 통합하여 테스트
- 시스템의 여러 부분이 함께 동작하는지 검증하는 것이 목적
E2E (End-to-End) 테스트
- E2E 테스트는 전체 애플리케이션 또는 시스템을 실제 사용자의 관점에서 테스트한다.
- 사용자의 시나리오를 시뮬레이션하여 애플리케이션의 각 계층이 통합되어 예상대로 동작하는지 확인한다.
- 프론트엔드, 백엔드, 데이터베이스, 외부 서비스 등 모든 구성 요소의 상호 작용을 검증한다.
- regression (회귀) 테스트에 적합하다
- 회귀(regression)는 소프트웨어 테스팅 용어로, 새로운 코드 변경이나 기능 추가 등으로 인해 이전에 정상적으로 작동하던 기존 기능이 예기치 않게 중단되거나 오작동하는 현상을 말한다.
비교
| 실행비용 | 수행시간 | |
|---|---|---|
| 단위테스트 | 하 | 빠름 |
| 통합테스트 | 중 | 중간 |
| E2E 테스트 | 상 | 느림 |
contract, a/b, stress 테스트 등 여러 테스트 개념도 있다
개발자가 어디 까지 테스트 하는지는 회사마다 다름
테스트 구조 및 원칙
Given - When - Then
FIRST - 좋은 테스트 원칙
테스트 케이스를 작성할 때 고려해야 할 원칙
내부 구현 사항을 자세히 테스트하지 않는다
내부 구현 사항은 자주 변경되기 때문에 실행 결과를 테스트하는 데 집중한다
Right-BICEP - 좋은 테스트 범위
테스트의 범위를 결정할 때 고려해야 할 요소들을 나타내는 원칙
CORRECT - 좋은 테스트 조건
테스트 케이스를 작성할 때 고려해야 할 조건들을 나타내는 원칙
프론트엔드에서의 테스트
프론트엔드 테스트는 일반 사용자와 동일하거나 유사한 환경에서 수행된다 (블랙 박스 테스트)
사용자가 프로그램에서 수행할 비즈니스 로직이나 모든 경우의 수를 고려해야 한다
적용해 본 방법
claude, chatgpt 같은 생성형 AI 툴을 적극적으로 사용해서 테스트 코드 작성 시간을 어느정도 줄일 수 있다는 생각이 들었다.
요구사항이 먼저 정의되어 있는 상황에서 생성형 AI에 테스팅 라이브러리, 요구사항, 테스트 원칙을 제공하면 직접 작성하는 것보다 빠르게 테스트 코드를 작성할 수 있다.
요구사항이 없이 이미 개발중인 상황에서는 위와 같은 인풋에 개발한 코드를 제공하면 같은 결과를 얻을 수 있다.
다만 테스트 코드 또한 일반 코드와 마찬가지로 유지 보수가 필요하다. 최대한 변경 가능성이 작게 작성하는 것이 좋다. 따라서 내부 구현 사항을 자세하게 테스트하는 것 보다 결과 값에 대하여 검증하는 것이 중요하다.
