비정상 테스트

GitLab에서 발생하는 불안정한 테스트(flaky test), 느린 테스트의 원인과 재현 방법, 해결 방법을 설명합니다.

비정상 테스트 # 불안정한 테스트 (Flaky tests) # 이 페이지는 GitLab의 불안정한 테스트(flaky test)를 이해하고 디버깅하기 위한 기술적 참고 자료를 제공합니다. 불안정한 테스트 관리, 모니터링 및 모범 사례에 관한 프로세스 정보는 Flaky Tests 핸드북 페이지 를 참조하세요. 불안정한 테스트란? # 가끔씩 실패하지만, 충분한 횟수로 재시도하면 결국 통과하는 테스트입니다. 불안정한 테스트를 로컬에서 재현하는 방법 # 로컬에서 실패 재현 CI job 로그에서 RSpec seed 를 찾습니다. 또는 while :; do bin/rspec <spec> || break; done 을 루프로 실행하여 seed 를 찾습니다. 다음 명령으로 스펙 실패를 이분 탐색(bisect)하여 예제를 줄입니다. bin/rspec --seed <이전에 찾은 값> --require ./config/initializers/macos.rb --bisect <spec> 남은 예제들을 살펴보고 상태 누출(state leakage)을 확인합니다. 예를 들어, let_it_be 로 생성된 레코드를 업데이트하는 것은 흔한 문제의 원인입니다. 수정 후 seed 를 사용하여 스펙을 다시 실행합니다. scripts/rspec_check_order_dependence 를 실행하여 스펙이 무작위 순서 로 실행될 수 있는지 확인합니다. while :; do bin/rspec <spec> || break; done 을 루프로 다시 실행하여(점심을 먹으며 기다립니다) 더 이상 불안정하지 않은지 확인합니다. 격리된 테스트 (Quarantined tests) # 불안정한 테스트가 master 의 개발을 차단하는 경우, 다른 개발자에게 미치는 영향을 방지하기 위해 해당 테스트를 격리해야 합니다. Test Quarantine Process 핸드북 페이지 에서는 다음을 포함한 격리 프로세스에 대한 포괄적인 지침을 제공합니다: 빠른 격리 프로세스 또는 장기 격리 프로세스를 사용해야 하는 경우 타임라인 기대치 및 소유권 책임 격리에서 테스트를 제거하는 방법 격리 소유권 및 에스컬레이션 절차 작동 방식 즉각적인 격리가 필요한 경우, 빠른 병합을 위해 빠른 격리 프로세스 를 사용하세요. 코드베이스에서 테스트를 격리하는 구현 세부 사항은 핸드북 페이지를 참조하세요. 자동 재시도 및 불안정한 테스트 탐지 # 실패한 테스트는 별도의 RSpec 프로세스에서 자동으로 한 번 재시도됩니다. 자세한 내용은 별도 프로세스에서 실패한 테스트 자동 재시도 를 참조하세요. 테스트가 불안정해지는 잠재적 원인 # 상태 누출 - flaky-test::state leak 설명 : 이전 테스트에서 데이터 상태가 누출되었습니다. 실제 원인은 이 불안정한 테스트가 아닐 가능성이 높습니다. 재현 난이도 : 보통. 일반적으로 실패하는 것을 재현할 때까지 동일한 스펙 파일을 반복 실행합니다. 해결 방법 : 이전 테스트 및/또는 테스트 데이터나 환경이 수정되는 위치를 수정하여 각 테