답변.

플레이키 테스트는 코드 변경 없이 외부 요인 때문에 통과하거나 실패할 수 있는 테스트입니다. 이들은 자동화에 대한 신뢰를 저하시킬 뿐만 아니라 CI/CD 프로세스를 어렵게 만듭니다.

질문의 역사: 플레이키 테스트에 대한 긴장은 대규모 E2E, 통합 및 UI 테스트의 출현과 함께 발생했습니다. 이 때 환경과 의존 서비스의 안정성이 보장되지 않았습니다. 처음에는 이러한 실패들을 무시하거나 "수동으로 재실행"했습니다.

문제:

• 플레이키 테스트는 테스트의 자동 실행을 불안정하게 만듭니다.
• 개발자들은 실제 오류를 잘못된 것으로 간주하며 빼먹기 시작합니다.
• 테스트 지원 시간이 증가하고 불안정한 결과를 수동으로 분석해야 합니다.

해결책:

1. 플레이키 테스트에 대한 별도 관리. 레이블링(예: @플레이키테스트)하거나 별도의 카테고리로 분리합니다.
2. 자동 재실행. 테스트가 실패할 경우 X회 반복 실행 — 항상 실패하지 않으면 테스트를 불안정한 것으로 표시합니다.
3. 불안정성의 원인 분석: 로그, 상태 스냅샷, 리소스 모니터링 사용(예: 불안정한 네트워크, 대기열 또는 GC 작업).
4. 점진적 수정: 테스트 환경 작업, 시나리오 단순화, 불안정한 의존성 마킹.

자동 재실행을 위한 코드 예시:

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # 테스트 코드

주요 특징:

• 플레이키 테스트를 실제 실패와 분리하는 것이 중요합니다.
• 단순히 "모든 것을 재실행"하는 것은 피해야 합니다 — 실제 버그는 놓쳐서는 안 됩니다.
• 테스트의 상태는 정기적으로 분석하고 문서화되어야 하며, 단순히 묵인해서는 안 됩니다.

꼬리 질문.

플레이키 테스트는 항상 인프라 문제인가요?

아니요, 플레이키는 비즈니스 로직 오류, 코드 경쟁 상태, 비동기성 또는 시간 관련 문제로 인해 발생할 수 있습니다.

실패한 테스트를 단순히 재실행하는 것으로 충분한가요?

아니요, 재실행은 문제를 숨기는 것일 뿐입니다. 원인을 찾아서 해결해야 합니다.

모든 불안정한 테스트를 삭제하는 것이 좋나요?

아니요, 그들은 일시적으로 격리하고 원인을 수정해야 하며, 단순히 영구적으로 제외해서는 안 됩니다.

일반적인 오류 및 안티 패턴

• 플레이키를 무시하여 심각한 버그를 놓치는 일.
• 원인 분석 없이 대량 재실행.
• 중요한 테스트를 플레이키로 표시하고 이를 수정하기 위한 조치를 취하지 않음.

실제 예

부정적 사례

프로젝트에서 플레이키 테스트는 단순히 레이블만 붙이고 더 이상 손대지 않았습니다. 그 문제는 "해결할 수 없는 문제"라고 여겼습니다.

장점:

• 잘못된 "빨간" 빌드 수 감소

단점:

• 실제 버그가 프로덕션으로 넘어감
• 결과에 대한 지속적인 수동 점검 필요

긍정적 사례

각 불안정한 테스트에 대해 자동 재실행과 불안정성에 대한 내부 관리를 도입했습니다. 정기적으로 원인에 대한 공동 리뷰를 실시하고 버그를 누적되면서 수정했습니다.

장점:

• 테스트 시스템의 안정성이 점차적으로 향상됨
• 새로운 플레이키를 빠르게 발견하고 수정

단점:

• 불안정성 분석 작업에 정기적인 리소스가 필요합니다.