프런트엔드 테스트 전략
테스트 전략은 결국 테스트 작성 및 운영에 들어가는 비용과, 속도를 기준으로 어떤 테스트의 비중을 높여야 할지에 대한 설계입니다.
본격적으로 설명하기 전에 각 전략에서 사용되는 기준에 대해 먼저 짚고 넘어가겠습니다.
- 비용(Cost, $): 더 많은 비용이 든다는 것은 지속적 통합 환경(Continuous integration environment)에서 테스트를 실행하는 실제 비용뿐만 아니라 엔지니어가 각 개별 테스트를 작성하고 유지 관리하는 데 걸리는 시간이 오래 걸린다는 것을 의미합니다. 비용이 클 수록 실패 포인트가 많아지므로 테스트가 중단될 가능성이 높아져 테스트를 분석하고 수정하는데 더 많은 시간이 소요됩니다.
- 속도(Speed): 더 상위 계층의 테스트일수록 테스트가 실행하는 코드가 더 많기 때문에 실행 속도가 느려집니다. 단위 테스트는 일반적으로 의존성이 없거나 해당 의존성을 모킹(mocking)할 수 있는 작은 단위의 기능을 테스트해 수천 라인의 코드를 단 몇 줄로 효과적으로 대체합니다.
그럼 이제 이 두 기준을 가지고 가장 유명하고 많이 언급되는 테스트 전략을 살펴보겠습니다.
테스트 피라미드

- 테스트 피라미드는 단위 테스트의 비중이 제일 높은 피라미드 구조입니다.
- 단위 테스트는 빠르게 모듈의 핵심 기능을 검증할 수 있기 때문에 단위 테스트의 비중을 가장 높게 두고 서비스 특화된 비즈니스 로직이나 UI 검증의 비중은 상대적으로 적게 두는 지표입니다.
- 그림에 있는 것처럼 UI나 서비스 로직은 여러 모듈의 조합을 검증해야 하기 때문에 자연스럽게 테스트 코드 작성 비용과 실행 시간이 오래 걸리기 때문에 다음과 같은 구조를 통해 빠른 피드백을 받고 결함을 정확하게 격리하고 수정하는 방법입니다.
- 상위 수준 테스트에서 실패하는 경우 기능 코드에 버그가 있을 뿐만 아니라 단위 테스트가 누락되거나 부정확한 것을 의미합니다.
- 따라서 높은 수준의 테스트에서 노출된 버그를 수정하기 전에 단위 테스트를 통해 버그를 복제해야 한다고 마틴 파울러는 조언합니다. 그런 다음 단위 테스트를 통해 버그가 죽은 상태로 유지되는지 확인하는 과정을 거쳐 장점을 누리라고 합니다.
테스트 피라미드를 주장하는 이유:
- 비용 효율성
- 단위 테스트는 작성과 유지보수가 상대적으로 저렴
- 실행 속도가 매우 빠름
- 버그를 초기에 발견하여 수정 비용 절감
- 안정성
- 단위 테스트는 격리된 환경에서 실행되어 더 안정적
- 외부 의존성이 적어 실패 원인 파악이 용이
- 테스트 실패 시 문제 범위가 명확함
- 개발자 피드백
- 빠른 피드백 루프로 개발 생산성 향상
- TDD 실천이 용이
테스트 트로피

- 여기서 Static은 코드를 작성할 때 오타와 타입에러를 확인한다. TypeScript나 ESLint 등을 통해 실행할 수 있습니다.