Fail Fast Testing

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

테스트 실행에 RSpec을 사용하는 애플리케이션에 대해, Merge Request의 변경 내용을 기반으로 테스트 수트의 하위 집합을 실행하는 Verify/Failfast 템플릿을 소개했습니다.

이 템플릿은 입력 파일 디렉터리을 허용하고 해당하는 테스트 파일 디렉터리을 반환하는 test_file_finder(tff) gem을 사용합니다.

tff는 루비 온 레일 프로젝트용으로 설계되었으며, 변경 내용으로 루비 파일이 감지될 때 실행되도록 Verify/FailFast 템플릿이 구성되어 있습니다. 기본적으로 이는 GitLab CI/CD 파이프라인의 .pre 스테이지에서 모든 다른 스테이지보다 먼저 실행됩니다.

예시 유즈 케이스

새 기능을 프로젝트에 추가하고 새 자동화된 테스트를 추가할 때 Fail fast testing은 유용합니다.

프로젝트에는 수천 개의 테스트가 있어서 완료하는 데 시간이 오래 걸릴 수 있습니다. 새 테스트가 통과될 것이라고 기대할 수 있지만 확인을 위해 모든 테스트가 완료될 때까지 기다려야 합니다. 이 작업은 병렬화를 사용하더라도 1시간 이상이 걸릴 수 있습니다.

Fail fast testing을 사용하면 파이프라인에서 보다 빠른 피드백 루프를 제공합니다. 새 테스트가 통과되고 새 기능이 다른 테스트를 망가뜨리지 않았음을 빠르게 파악할 수 있습니다.

전제 조건

이 템플릿은 다음이 필요합니다:

빠른 RSpec 실패 구성

우리는 다음과 같은 일반 RSpec 구성을 시작점으로 사용합니다. 머지 요청 파이프라인에서 프로젝트 젬을 모두 설치하고 rspec을 실행합니다. 

rspec-complete:
  stage: test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - bundle install
    - bundle exec rspec

전체 스위트 대신 가장 관련있는 테스트를 먼저 실행하려면 다음을 CI/CD 구성에 포함하세요. 

include:
  - template: Verify/FailFast.gitlab-ci.yml

작업을 사용자 정의하려면 템플릿을 덮어씌우기 위해 특정 옵션을 설정할 수 있습니다. 예를 들어 기본 Docker 이미지를 덮어쓰려면: 

include:
  - template: Verify/FailFast.gitlab-ci.yml

rspec-rails-modified-path-specs:
  image: custom-docker-image-with-ruby

예시 테스트 로드

예시로, 우리의 루비 온 레일 앱 스펙 스위트는 각 모델에 대해 100가지의 스펙으로 이루어져 있다고 가정해 봅시다.

만약 루비 파일이 변경되지 않았다면:

  • rspec-rails-modified-paths-specs은 어떤 테스트도 실행하지 않습니다.
  • rspec-complete은 1000가지의 전체 스위트를 실행합니다.

만약 한 가지의 루비 모델, 예를 들어 app/models/example.rb, 가 변경되었다면 rspec-rails-modified-paths-specs은 example.rb의 100가지 테스트를 실행합니다:

  • 이 100가지 테스트가 모두 통과되면, 전체 1000가지 테스트 스위트를 실행합니다.
  • 이 100가지 테스트 중 하나라도 실패한다면, 이러한 테스트는 빠르게 실패하고 rspec-complete는 어떤 테스트도 실행하지 않습니다.

최종적으로 이러한 경우는 자원과 시간을 절약하여 전체 1000가지 테스트 스위트를 실행하지 않습니다.