실패 빠른 테스트

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

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

이 템플릿은 입력으로 파일 디렉터리을 받아들이고 해당 파일 디렉터리과 관련이 있다고 믿는 spec(테스트) 파일 디렉터리을 반환하는 test_file_finder (tff) gem을 사용합니다.

tff는 Ruby on Rails 프로젝트를 위해 설계되었으므로 Verify/FailFast 템플릿은 Ruby 파일의 변경이 감지될 때 실행되도록 구성되어 있습니다. 기본 설정으로는 GitLab CI/CD 파이프라인의 .pre 스테이지에서 다른 모든 스테이지보다 먼저 실행됩니다.

사용 사례 예시

실패 빠른 테스트는 프로젝트에 새 기능을 추가하고 새 자동화된 테스트를 추가할 때 유용합니다.

프로젝트에는 실행에 오랜 시간이 걸리는 수십만 개의 테스트가 있을 수 있습니다. 새 테스트가 통과될 것으로 예상할 수 있지만 확인하기 위해 모든 테스트가 완료되길 기다려야 합니다. 이러한 프로세스는 병렬화를 사용할 때에도 1시간 이상 소요될 수 있습니다.

실패 빠른 테스트를 사용하면 파이프라인으로부터 보다 빠른 피드백 루프를 제공합니다. 이를 통해 새 테스트가 통과되고 새 기능이 다른 테스트를 망가뜨리지 않았음을 빨리 알 수 있습니다.

전제 조건

이 템플릿을 사용하려면 다음이 필요합니다:

빠른 RSpec 실패 구성

우리는 다음 일반적인 RSpec 구성을 시작점으로 사용합니다. 해당 프로젝트 모든 gem을 설치하고, Merge Request 파이프라인에서만 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

예시 테스트 로딩

설명을 위해, 우리의 Rails 앱 스펙 스위트는 각 모델당 100개의 테스트로 구성되어 있다고 가정해봅시다.

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

  • rspec-rails-modified-paths-specs는 어떠한 테스트도 실행하지 않습니다.
  • rspec-complete는 1000개의 테스트 전체를 실행합니다.

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

  • 이 100개의 테스트가 모두 통과한다면, 1000개의 전체 rspec-complete 스위트가 실행됩니다.
  • 이 100개의 테스트 중 하나라도 실패한다면, 그들은 빠르게 실패하고, rspec-complete는 어떠한 테스트도 실행하지 않습니다.

마지막 경우는 전체 1000개의 테스트 스위트가 실행되지 않아 자원과 시간을 절약합니다.