1. 탄생 배경

기존의 단위 테스트(Unit Testing)와 통합 테스트(Integration Testing)가 가진 한계를 극복하기 위해 만들어졌습니다.

  • 단위 테스트(Unit Testing) : 개별 함수클래스 등 작은 코드 단위를 테스트
    • 한계점
      • 시스템 전체의 흐름이나 상호작용을 확인하기 어려움
      • 실제 사용자 시나리오를 반영하지 못함
  • 통합 테스트(Integration Testing): 여러 모듈이나 컴포넌트를 통합한 테스트
    • 한계점
      • 전체 시스템 관점에서의 테스트 부족
      • 외부 시스템과의 연동 문제를 발견하기 어려움

두 테스트의 주요 문제점

  • 전체 시스템 흐름 검증 부족
  • 사용자 관점 부재
  • 시스템 간 의존성 문제 - 외부 시스템, API, 데이터베이스와의 연동에서 발생하는 의존성 문제
  • 데이터 무결성 확인 어려움 -  시스템 전반에 걸친 데이터 흐름을 확인하기 어려움
  • 복잡한 버그 미검출  - 여러 모듈컴포넌트의 상호 작용에서 발생하는 복잡한 버그

# 모듈(Module)

- 여러 개의 함수나 클래스를 모아 특정 기능을 수행하는 코드의 단위

    (예시) 사용자 관리 모듈: 회원가입, 로그인, 비밀번호 변경 등과 관련된 기능들을 모아 놓은 것

 

# 컴포넌트(Component) 

- 시스템에서 특정 기능이나 역할을 수행하는 독립적인 단위

- 독립적이고 재사용 가능한 단위로, 하나 이상의 모듈로 구성

    (예시) 인증 컴포넌트 : 사용자의 신원을 확인하고, 인증된 사용자에게 접근 권한부여 (jwt 토큰 발급, 검증 등) 

2. 사용하는 이유

  • 전체 시스템 검증: E2E 테스트는 전체 애플리케이션의 기능을 검증하여 시스템이 통합적으로 잘 작동하는지를 확인
  • 사용자 경험 반영: 실제 사용자 행동을 시뮬레이션 및 검증하여 시스템의 품질 보장
  • 시스템 간 의존성 문제 해결 : 외부 시스템과의 연동에서 발생하는 문제를 효과적으로 테스트
  • 데이터 무결성 확인 :  데이터가 시스템 전반에 걸쳐 올바르게 전달되고 처리되는지 검증.
  • 복잡한 워크플로우 테스트: 단순한 기능 테스트로는 발견하기 어려운 복잡한 시나리오나 예외 상황을 테스트

즉, 프로덕션 환경에서 발생할 수 있는 문제를 미리 발견하여 배포 후의 리스크를 감소시키기 위해서다.

3. 장점과 단점

장점:

  • 사용자 중심의 테스트: 실제 사용자의 행동을 기반으로 테스트하여 사용자 경험을 향상
  • 높은 신뢰성: 전체 시스템의 기능을 검증하기 때문에 배포 전에 시스템의 안정성을 높일 수 있습니다.
  • 문제 조기 발견: 통합된 환경에서의 문제점을 미리 발견하여 수정 비용을 줄입니다.
  • 비즈니스 로직 검증 : 실제 시나리오를 테스트함으로써 비즈니스 로직이 의도한 대로 동작하는지 확인할 수 있습니다.

단점:

  • 시간과 비용 소모: 테스트 범위가 넓어 실행 시간과 유지 보수 비용이 증가할 수 있습니다.
  • 복잡성 증가: 다양한 시나리오를 커버하려면 테스트 스크립트가 복잡해질 수 있습니다.
  • 테스트 불안정성: 작은 UI 변화나 환경 변화에도 테스트가 실패할 수 있어 민감하게 반응합니다.
  • 테스트 유지보수 어려움 : 작은 변경에도 테스트 스크립트 수정이 필요할 수 있습니다.

4. 요약

E2E 테스트

  • 기존 테스트 방식의 한계를 보완하여 전체 시스템 동작과 사용자 경험을 종합적으로 검증

도입 효과

  • 더 나은 품질의 소프트웨어 개발 가능.
  • 사용자에게 안정적이고 신뢰성 있는 서비스 제공.

E2E 테스트는 시스템 전체의 품질을 보장하기 위한 중요한 도구이지만, 효율적인 테스트 전략을 수립하여 단점을 최소화하는 것이 중요

 

탄생배경

전통적인 애플리케이션 배포방식에서 자주 마주하는 문제점 "It works on my machine":

  • 개발 환경과 운영 환경의 불일치
  • 복잡한 환경 설정과 종속성 관리의 어려움

이러한 문제를 해결하기 위해, 애플리케이션을 어디서나 동일한 환경에서 실행할 수 있는 기술의 필요성이 대두되어습니다.

그 결과, 애플리케이션을 컨테이너로 패키징하여 어디서나 동일하게 실행할 수 있게 해주는 가상화 플랫폼인 Docker 가 탄생하게 되었습니다.

Docker 를 사용하는 이유

특징  설명
컨테이너화 (Containerization) 애플리케이션과 그 종속성을 하나의 컨테이너로 묶어 일관된 실행 환경을 제공
이식성 (Portability) 도커를 지원하는 환경에서 애플리케이션을 쉽게 이식가능 →개발, 테스트, 배포과정의 단순화
격리성 (Isolation) 각 컨테이너는 자체 격리된 환경에서 실행되어서 애플리케이션 간의 충돌을 방지
효율성 (Efficiency)  호스트 시스템의 커널을 공유하여 가상머신을 사용하는 것에 비해 리소스 오버헤드가 감소
확장성(Scalability) 컨테이너는 수요에 따라 애플리케이션을 쉽게 확장하거나 축소 가능
재현성(Reproducibility) Docker 이미지는 버전 관리되고 공유될 수 있어 애플리케이션이 일관되게 배포되도록 보장

장점

  • 일관된 환경 제공: 개발부터 운영까지 동일한 환경을 유지하여 환경 불일치로 인한 문제를 최소화
  • 신속한 배포 및 롤백: 이미지 기반 배포로 빠른 배포와 롤백이 가능
  • 유연한 스케일링: 컨테이너 오케스트레이션 도구(Kubernetes 등)를 사용하여 수요에 따라 쉽게 확장하거나 축소가능
  • 리소스 효율성: 시스템 자원을 효율적으로 사용하여 비용 절감에 도움
  • 풍부한 생태계: Docker Hub 등 다양한 이미지와 커뮤니티 지원이 활발
  • CI/CD 파이프라인 통합 용이

단점

  • 보안 문제: 호스트 커널을 공유하기 때문에 가상 머신보다 보안 격리가 약할 수 있음
  • 복잡한 관리: 다수의 컨테이너 관리와 오케스트레이션이 복잡할 수 있음.
  • 윈도우 지원 제한: 초기에는 리눅스 중심으로 개발되어 윈도우 환경에서 제약이 있을 수 있습니다.
  • 디버깅 어려움: 컨테이너 내부의 문제를 진단하고 디버깅하는 데 어려움이 있을 수 있습니다.

Common Use Cases

  • Web Applications: Deploying and scaling web applications.
  • Microservices Architecture: Building and managing distributed applications composed of small, independent services.
  • Data Science: Running data science pipelines and machine learning models.
  • Continuous Integration and Continuous Delivery (CI/CD): Automating the testing and deployment of applications.

+ Recent posts