빌드가 빨간색으로 바뀌고 누군가가 “재실행”을 클릭하면 통과하고 모두가 계속 진행합니다. 무해해 보이지만 불안정한 테스트는 테스트 스위트가 가지고 있는 가장 가치 있는 것, 즉 테스트 스위트에 대한 사람들의 신뢰를 천천히 파괴합니다. 실패가 일반적으로 소음인 경우 실제 버그도 전달됩니다.

이 가이드에서는 테스트가 불안정해지는 이유와 각 원인을 올바르게 해결하는 방법을 다룹니다. Python 3.13에서 타이밍 및 공유 상태 데모를 실행했으며 표시된 숫자는 해당 실행에서 나온 것입니다. 이는 벗겨짐을 쉽게 볼 수 있도록 설계된 소규모 데모이므로 실패율이 다를 수 있습니다.

불안정한 테스트란 무엇입니까?

불안정한 테스트는 동일한 코드에서 다른 결과를 제공합니다. 제품에 아무것도 변경되지 않았음에도 불구하고 한 실행에서는 통과하고 다음 실행에서는 실패합니다. 테스트에 결함이 있거나 코드에 실제 간헐적인 버그가 포함되어 있을 수 있습니다. 두 번째 가능성은 바로 왜 단순히 무시해서는 안 되는 이유입니다.

불안정한 테스트에 비용이 많이 드는 이유

• 신뢰를 잃었습니다. 사람들이 빨간색이 “아마도 불안정함”을 의미한다고 생각하면 실제 실패에 대한 조사를 중단합니다.
• 시간 낭비. 개발자는 파이프라인을 다시 실행하고 변경 사항과 관련 없는 오류를 조사하는 데 몇 시간을 소비합니다.
• 더 느린 전달. 재실행 시 대기를 병합하고 해제하여 CI/CD의 요점을 약화시킵니다.
• 숨겨진 버그. 제품의 경쟁 조건은 테스트 소음처럼 보일 수 있으며 이는 생산에 해를 끼치는 요소입니다.

일반적인 원인 개요

원인 1: 타이밍 및 고정된 수면

이것이 가장 일반적인 원인입니다. 테스트에서는 고정된 지연 후에 백그라운드 작업이 완료된다고 가정합니다. 효과를 확인하기 위해 작업에 최대 2ms가 소요되고 테스트는 확인하기 전에 단 1ms만 기다리는 작은 테스트를 작성했습니다.

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

해결 방법은 넉넉한 상한을 적용하여 실제 조건이 나올 때까지 기다리는 것입니다.

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

각 버전을 200번 실행했습니다.

결과는 단순한 신뢰성 그 이상입니다. 고정 버전은 작업이 완료되는 순간 이동하므로 일반적으로 속도도 더 빠릅니다. 대기 시간이 길어지면 첫 번째 버전의 실패 빈도가 줄어들지만 모든 실행 속도가 느려지고 사용량이 많은 CI 시스템에서는 여전히 실패할 수 있습니다.

브라우저 테스트에서도 동일한 원칙이 적용됩니다. time.sleep 대신 극작가의 자동 대기 또는 명시적인 Selenium 대기를 사용하십시오.

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

원인 2: 공유 상태 및 테스트 순서

테스트가 데이터를 공유하면 하나가 다른 하나에 영향을 미칠 수 있으며 결과는 실행 순서에 따라 달라집니다. 이 두 테스트는 하나의 공유 목록을 사용합니다.

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

우리의 실행에서는 이를 확인했으며, 이것이 바로 제품군이 몇 달 동안 통과하다가 누군가가 병렬 실행이나 무작위 순서 플러그인을 추가하면 중단될 수 있는 이유입니다. 치료법은 격리입니다.

• 각 테스트에 새로운 데이터를 제공하고 이를 설정하고 정리하는 픽스처를 사용합니다. 우리의 pytest 튜토리얼이 그 방법을 보여줍니다.
• 공유된 “테스트 사용자” 대신 임의의 접미사가 붙은 이메일과 같은 고유한 레코드를 생성합니다.
• 데이터베이스 테스트를 트랜잭션으로 래핑하고 설정에서 허용하는 경우 롤백합니다.
• 정기적으로 무작위 순서로 테스트를 실행하여 이러한 문제가 조기에 나타나도록 하십시오.

원인 3: 날짜, 시간대 및 임의성

일주일 내내 통과한 테스트는 토요일, 자정 또는 매월 마지막 날에 실패할 수 있습니다. 논리 내부의 시계를 읽는 대신 시간을 입력으로 만드세요.

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

그 테스트는 어느 날이든 같은 답을 줍니다. 마찬가지로 테스트에서 임의 값에 대한 고정 시드를 설정하고 임의 데이터를 사용할 때 이를 기록하여 오류를 재현할 수 있습니다. 세트, 외부 소스의 사전 또는 ORDER BY이 없는 데이터베이스 쿼리의 특정 순서를 가정하지 마십시오.

원인 4: 취약한 선택기

div:nth-child(3) > span이 있는 버튼을 찾는 테스트는 레이아웃을 조정할 때 중단되며 일부 화면 크기 또는 변형에서만 실패할 수 있습니다. 사용자가 보는 내용이나 전용 테스트 속성을 기반으로 한 로케이터를 선호합니다. 극작가 로케이터에 대한 가이드에서는 이를 사용해 보는 순서를 설명합니다. 애니메이션은 또 다른 빈번한 문제 원인이므로 테스트 환경에서는 애니메이션을 비활성화하는 것이 좋습니다.

원인 5: 외부 서비스 및 네트워크

테스트에서 실제 결제 제공업체 또는 타사 API를 호출하는 경우 해당 결과는 다른 사람의 가동 시간 및 속도 제한에 따라 달라집니다. 대부분의 테스트에서 이러한 호출을 모의하고 실제 서비스에 대해 소수의 별도 계약 확인을 유지하여 변경 사항이 있는지 계속 알 수 있도록 합니다. 단위 테스트와 통합 테스트 가이드에서는 이러한 테스트를 분할하는 방법을 설명합니다.

불안정한 테스트를 진단하는 방법

1. 확인합니다. 변경사항 없이 테스트를 여러 번 실행합니다. pytest를 사용하면 간단한 쉘 루프가 작동하고 pytest-repeat와 같은 플러그인이 --count=100을 제공합니다.
2. 증거를 기록합니다. 각 실패에 대한 로그, 스크린샷 및 추적을 저장합니다. Playwright의 추적 뷰어는 여기서 특히 유용합니다.
3. 조건을 강조하세요. 제한된 CPU를 사용하여 병렬 또는 무작위 순서로 실행하세요. 자주 실패하게 하면 공부하기가 더 쉬워집니다.
4. 단독으로 테스트하세요. 항상 단독으로 통과하지만 제품군에서 실패하면 공유 상태를 의심해 보세요.
5. 패턴을 찾아보세요. 어떤 기계, 시간대, 주변 테스트가 관련되어 있는지 확인하세요.
6. 제품을 확인하세요. 이것이 애플리케이션에서 실제 경쟁 조건이 될 수 있는지 솔직하게 물어보세요.

자동 재시도가 해결되었나요?

재시도는 유용한 단기 안전망이며 치료법은 아닙니다. CI에서 한 번의 자동 재시도를 통해 조사하는 동안 작업을 계속 진행할 수 있지만 통과하려면 재시도가 필요한 테스트는 여전히 무언가를 알려줍니다. 더 나쁜 것은 20%의 시간 동안 실패하는 실제 간헐적인 제품 버그는 일반적으로 눈에 띄지 않게 재시도를 통과한다는 것입니다.

다음 규칙에 따라 재시도를 사용하세요. 한두 번으로 제한하고, 필요한 모든 테스트를 기록하고, 해당 목록을 할 일 목록으로 처리하세요. “재시도 통과”로 보고된 테스트는 성공이 아닌 조사 문제로 간주되어야 합니다.

불안정한 테스트를 위한 팀 프로세스

1. 측정. 어떤 테스트가 실패했는지 추적한 다음 동일한 커밋을 통과합니다. 많은 CI 도구와 테스트 보고자가 이를 보여줄 수 있습니다.
2. 격리. 확인된 불안정한 테스트를 차단 실행에서 제외하여 모든 사람을 방해하지 않고 계속 실행하고 추적하도록 합니다.
3. 소유자와 기한을 지정하세요. 기한이 없는 격리는 묘지가 됩니다.
4. 수정 또는 삭제. 수정할 가치가 없는 테스트인 경우 해당 테스트를 제거하고 해당 적용 범위가 다른 곳에 여전히 존재하는지 확인하세요.
5. 예방. 병합하기 전에 새 테스트를 여러 번 실행하세요. 50번 실행에 한 번 실패하는 테스트는 6개월 후에 잡는 것보다 지금 잡는 것이 더 좋습니다.

불안정한 테스트를 배경 소음이 아닌 우선순위가 있는 버그로 처리합니다. 심각도 대 우선순위에서 다룬 심각도와 우선순위가 여기에도 적용됩니다. 결함이 널리 퍼져 있는 경우에는 더 광범위한 테스트 자동화 실수에 대해 읽어보고 브라우저 수준에서 테스트가 너무 많은지 생각해 보세요.

마무리

불안정한 테스트는 무작위로 느껴지지만 그런 경우는 거의 없습니다. 거의 모든 사람은 항상 사실이 아닌 시간, 순서, 데이터 또는 환경에 대한 가정에 도달합니다. 이번 주 파이프라인에서 가장 자주 실패하는 테스트를 선택하세요. 50번 실행하고 가정을 찾아서 완전히 수정하세요. 하나의 실제 수정 사항은 팀에게 100번 이상의 재방송을 통해 가르쳐줍니다.

자주 묻는 질문

계속 학습하세요