불안정한 테스트(Flaky tests)란 동일한 코드 버전에서 통과하기도 하고 실패하기도 하는 테스트로, 테스트 결과의 신호를 약화시키고 지속적 통합(CI) 파이프라인을 방해합니다. 코드 기반 불안정성 탐지기들은 강력한 벤치마크 결과를 보고하지만, 실제 사용은 여전히 제한적입니다. 우리는 이 분야가 잘못된 문제를 연구하고 있다고 주장합니다. 즉, 불안정성은 테스트 코드의 정적인 속성이 아니며, 테스트가 불안정한지 여부를 결정하는 데 필요한 정보를 종종 갖추고 있지 못합니다. 테스트 코드를 기반으로 작동하는 세 가지 코드 기반 탐지기를 분석한 결과, 널리 사용되는 벤치마크에는 보고된 F1 점수를 부풀리는 지름길(shortcuts)이 포함되어 있으며 평가 프로토콜은 일반화 가능성을 과대평가하고 있음을 발견했습니다. 이러한 지름거리를 통제하기 위해 두 가지 데이터셋을 구축했습니다. 첫 번째인 C-IDoFT는 57개 GitHub 프로젝트의 54,468개 단위 테스트(unit tests)를 포함하며, IDoFT의 불안정한 테스트 중 개발자가 확인한 하위 집합만을 유지하고, 고정된 버전의 불안정한 테스트 대신 반복 실행을 통해 비불안정한 클래스만 재구축합니다. C-IDoFT는 재사용을 위한 벤치마크가 아니라 통제된 반사실(counterfactual)입니다. 두 가지 발표된 탐지기의 CodeBERT 재구현 모델은 공개된 교차 검증 프로토콜 하에서 상수 기준선(constant baselines)보다 훨씬 높은 점수를 기록했지만, 프로젝트를 분리하여 테스트했을 때는 그들보다 나은 성능을 보이지 못했습니다. 높은 점수는 테스트 코드 자체가 아니라 라벨링 지름거리와 평가 프로토콜에 의존하고 있었습니다. 테스트 코드로부터 일반적으로 인식 가능한 불안정성 유형으로 제한된 벤치마크인 FlakeBench와 동일한 프로젝트 분리 프로토콜에서, 이 모델들은 거의 모든 불안정한 테스트를 식별했습니다. 두 번째 데이터셋은 CI 로그에서 채굴되었으며, 동일 커밋에서 통과하기도 하고 실패하기도 한 86개의 불안정한 엔드투엔드(end-to-end) 테스트를 포함합니다. 테스트 코드와 CI 로그는 이 중 42%의 원인을 제공했으며, 나머지 58%는 추가적인 실행 증거가 필요했습니다. 우리는 불안정성 예측을 포기하기보다는, 관찰된 실패가 불안정한지 여부와 주어진 실행 환경에서 테스트가 실패할 가능성이 얼마나 높은지에 초점을 맞춰 재구성합니다. 우리의 데이터셋과 CI 채굴 방식은 이러한 방향을 뒷받침합니다.