[xUnit 테스트 패턴] 06장 - 테스트 자동화 전략

06장 - 테스트 자동화 전략

무엇이 전략인가

  • 어떤 테스트를 자동화할 것인가?
  • 테스트틀 자동화하기 위해 어떤 툴을 쓸 것인가?
  • 테스트 픽스처를 어떻게 관리할 것인가?
  • 어떻게 하면 시스템이 쉽게 테스트되고 SUT와 상호작용할 수 있게 보장할 것인가?

어떤 종류의 테스트를 자동화해야 하는가

  • 기능별 테스트
    • 특정 입력에 대한 SUT의 동작을 검증
  • 교차 기능 테스트
    • 특정 기능 전체에 걸쳐 시스템 동작의 다양한 측면을 검증

기능별 테스트

  • 기능
    • 비즈니스에 관련된 것
    • 동작에 관련 된 요구 사항들
      • 유스케이스나 기능, 사용자 스토리, 테스트 시나리오
  • 고객 테스트
    • 전체 시스템의 동작을 검증
    • 하나 이상의 유스케이스나 기능, 사용자 스토리의 시나리오에 해당
    • 최종 사용자도 테스트에 명시된 동작을 알아볼 수 있어야 한다.
  • 단위 테스트
    • 클래스나 메소드의 동작을 검증
    • 개발자가 스스로 피룡해서 작성
    • 단위의 특정 동작이 어떻게 돼야 하는지를 테스트 형태로 요약 가능
  • 컴포넌트 테스트
    • 클래스의 집합으로 이뤄진 컴포넌트를 검증
    • 단위 테스트와 고객 테스트의 중간 정도에 위치
  • 실패 주입 테스트
    • 단위 테스트나 컴포넌트 테스트 수준 정도의 또 하나의 테스트
    • 애플리케이션의 일부를 변경하지 않으면서 실패 주입 테스트의 자동화는 어렵다.

교차 기능 테스트

  • 특성 테스트
    • 성능 테스트
      • 응답 시간 테스트
      • 수용 능력 테스트
      • 스트레스 테스트
    • xUnit 프레임워크는 자동 성능 테스트용으로는 적합하지 않음.
      • 다른 방법으로 자동화 해야 함.(ex : JMeter))
  • 사용성 테스트
    • SUT 사용이 얼마나 쉬운지에 대해 사람들의 주관적인 평가가 필요하므로 자동화가 어렵다.
  • 탐험적 테스팅
    • 제품에 일관성이 있는지 확인하는 방법
    • 가설을 세우고 그 가설을 검증할 테스트를 설계한 후 테스트하기 위해 제품을 실행
    • 탐험적 테스팅은 자동화할 수 없다.

어떤 테스트 자동화에는 어떤 도구를 사용하는가

  • 기록 테스트 접근법
    • 수동으로 테스트할 때 발생하는 SUT와의 상호작용을 기록하는 도구 사용
    • 파일이나 데이터베이스에 저장하고 스크립트 형태로 바꿔 다른 버전의 SUT를 테스트할 때 사용
    • 단점
      • 깨지기 쉬운 테스트가 된다.
  • 직접 작성한 스크립트 기반 테스트
    • xUnit
    • 배치파일, 매크로 언어 등등

xUnit 소개

  • 테스트를 자동화하는데 사용

어떤 테스트 픽스처 전략을 사용하는가

무엇이 픽스처인가

  • 픽스처와 픽스처를 생성하는 테스트케이스 클래스를 구분
    • JUnit 계통

주요 픽스처 전략

  설치 코드 해체 코드 설치/해체 호출
1회용 신선한 픽스처 필요    
지속되는 신선한 픽스처 필요 필요  
공유 픽스처 필요 필요 필요

1회용 신선한 픽스처

  • 각 테스트가 실행될 때 임시 신선한 픽스처를 생성
  • 테스트가 스스로 자신이 필요로 하는 객체나 테이터를 생성
  • 완벽한 독립 보장
  • 단점
    • 모든 테스트에서 객체를 생성하므로 CPU 사이클이 추가로 필요
    • 다른 픽스처 사용할 때 보다 느리게 실행 될 수 있다.

지속되는 신선한 픽스처

  • 테스트하려는 컴포넌트가 데이터베이스나 다른 것과 강하게 결합돼 있을 경우 쓸 수 밖에 없다.
  • 테스트가 끝날 때마다 픽스처 해체 코드를 써야 한다.
  • 픽스처를 지속시키지 위해 데이터베이스나 파일 시스템 등을 사용한다면 느린 테스트가 될 수 있다.
    • 해결책
      • 최소 픽스처를 생성하라.
      • 테스트 대역으로 바꿔 생성 속도 높여라.
      • 픽스처에서 참조는 하되 변경되지 않는 부분에 대해서는 불변 공유 픽스처를 쓴다.

공유 픽스처 전략

  • 많은 테스트가 하나의 테스트 픽스처 객체를 재사용
  • 장점
    • 픽스처의 설치, 해체에 드는 긴 런타임을 줄일 수 있다.
  • 단점
    • 서로 반응하는 테스트가 된다.
  • 가급적이면 사용하지 않는게 좋다.
  • 쓰게 되면 불변 공유 픽스처 사용으로 변경되는 부분을 적게 만든다.

테스트 용이성을 보장하는 방법

테스트 나중 - 각오가 돼 있는가

  • 테스트 자동화 중 가장 힘들고 생산성도 가장 낮다.

테스트하기 쉬운 설계 - 미리 하기

테스트 주도 테스트 용이성

  • 테스트하기 쉽게 설계하지 않아도 된다.
    • 테스트 용이성은 자연스레 따라옴

제어 위치와 관찰 위치

  • 제어 위치
    • 소프트웨어가 테스트를 위해 뭔가를 하게 시킬 수 있다.
    • 일부 제어 위치는 테스트만을 위해 제공된다.
      • 제품 코드에서는 사용하지 않아야 한다.
  • 관찰 위치
    • SUT나 DOC의 테스트 후 상태를 얻어와 결과 검증 단계에서 SUT의 동작을 확인
    • SUT와 이에 연결된 다른 컴포넌트와의 상호작용을 감시하는 목적으로도 쓰임
    • 뒷문 검증의 한 예가 된다.

상호작용 방식과 테스트 용이성 패턴

  • 왕복 테스트
    • SUT를 public 인터페이스(정문)만 이용해 접근한다.
    • 캡슐화를 해치지 않는다.
  • 레이어 횡단 테스트
    • API를 통해 SUT를 실행한 후 테스트 스파이 같은 테스트 대역을 이용한 뒷문으로 뭐가 나오는지를 지켜보는 방법
      • 비기능 요구 사항 같은 것들을 검증하는데 효과적인 테스팅 기법