How Far Are We from Detecting Flaky Tests? On the Limits of Code-Based Detection

기술 요약: 코드 기반 플래키 테스트 탐지의 한계에 대하여

문제 정의
플래키 테스트(Flaky tests)—동일한 코드 버전에서 통과와 실패를 반복하는 테스트)—는 테스트 결과에 대한 신뢰를 떨어뜨리고 개발자의 시간을 낭비함으로써 지속적 통합(CI)을 저해한다. 정적 코드 기반 탐지기(어휘 패턴, 코드 메트릭 또는 CodeBERT와 같은 대규모 언어 모델 사용)를 사용하여 재실행 없이 플래키성을 예측하려는 방대한 연구가 존재하지만, 산업계의 도입은 여전히 제한적이다. 최근 연구들에 따르면, 보고된 높은 성능(예: F1 점수 > 0.90)은 실험적 결함이나 플래키성이 테스트 코드의 정적 속성이라는 근본적인 전제 때문에 발생하는 취약한 결과일 수 있다. 본 논문은 이 분야가 잘못된 문제를 연구하고 있다고 주장한다. 즉, 플래키성은 종종 실행 환경과의 런타임 상호작용에서 발생하며, 이는 테스트 코드 자체만으로는 플래키한 테스트와 그렇지 않은 테스트를 구분하는 데 필요한 정보를 충분히 갖추지 못함을 의미한다.

방법론
저자들은 세 가지 저명한 코드 기반 탐지기(Flakify, FlakyQ, FlakyXBert)를 단일하고 엄격한 프로토콜을 사용하여 철저하게 재현 및 재평가하였다. 연구는 다음 세 단계로 진행된다:

1. 재현 및 아티팩트 감사: 저자들은 공식 복제 패키지를 사용하여 세 가지 탐지기를 재현하였다. 그들은 데이터 누수(data leakage)와 지름길(shortcuts)에 대해 평가 프로토콜과 데이터셋을 감사하였다. 구체적으로, 교차 검증 시 데이터 누수(폴드 간 모델 가중치가 재초기화되지 않는 현상)와 "수정 커밋(fix-commit)" 지름길(비플래키 레이블이 플래키 테스트의 개발자 수정 버전을 통해 도출되어, 모델이 플래키 신호가 아닌 표면적 유사성을 통해 이용할 수 있는 유사한 코드 쌍을 생성하는 현상)을 다루었다.
2. C-IDoFT(통제된 반사실적 데이터셋) 구축: 레이블링 지름길의 영향을 격리하기 위해 저자들은 C-IDoFT를 구축하였다. 이 데이터셋은 기존 IDoFT 벤치마크의 개발자 확인 플래키 테스트는 유지하되, 비플래키 클래스를 재구성한다. 플래키 테스트의 수정 버전을 사용하는 대신, 비플래키 레이블은 테스트 모듈의 500회 반복 실행을 통해 도출되었다. 이 데이터셋은 코드 기반 탐지기가 "fix-commit" 지름길이 제거되고 프로젝트가 분리된(project-disjoint) 평가 환경에서도 일반화될 수 있는지 테스트하는 대조군 역할을 한다.
3. FlakeCI(CI 마이닝 코퍼스) 구축: 복잡한 시스템 내에서의 플래키 신호의 출처를 조사하기 위해, 저자들은 GitHub Actions에서 450,000개 이상의 CI 실행 기록을 마이닝하여 FlakeCI를 구축하였다. 이 데이터셋은 동일한 커밋에서 통과와 실패를 모두 경험한 86개의 확인된 플래키 엔드 투 엔드(E2E) 테스트를 포함한다. 저자들은 테스트 코드와 CI 로그를 수동으로 분석하여, 이러한 아티팩트만으로 플래키의 근본 원인을 규명할 수 있는지 판단하였다.

주요 결과

• 재현 및 데이터 누수: 데이터 누수를 해결하고(폴드당 모델 재로드) 프로젝트 분리 평가를 적용했을 때, Flakify와 FlakyQ의 성능은 붕괴되었다. IDoFT 벤치마크에서 가중 F1 점수는 약 0.95에서 0.80으로 떨어졌으며, 이는 "항상 플래키함(always-flaky)"을 가정하는 다수 클래스 베이스라인과 일치한다. FlakeFlagger 데이터셋에서 플래키 클래스의 F1 점수는 0.07로 떨어져 베이스라인을 상회하지 못했다. FlakyXBert의 성능 또한 다른 프로젝트의 데이터를 의도치 않게 사용한 노트북 출력값을 교정한 후, 0.94에서 0.83으로 크게 하락했다.
• C-IDoFT 평가: "fix-commit" 지름길을 제거하고 재실행으로 확인된 비플래키 레이블을 사용한 통제된 C-IDoFT 데이터셋에서, CodeBERT 기반 재구현 모델들(Flakify+ 및 FlakyLens+)은 프로젝트 분리 설정에서 상수 베이스라인보다 나은 성과를 보이지 못했다. 이들의 플래키 클래스 F1 점수는 각각 0.035와 0.070이었으며, 이는 "항상 플래키함" 베이스라인인 0.054와 비교해도 우위에 있지 않았다. 그러나 프로젝트 중첩을 허용하는 원래의 무작위 교차 검증 프로토콜 하에서는 동일한 모델들이 높은 점수(F1 > 0.68)를 기록하였는데, 이는 외견상의 탐지 능력이 일반적인 플래키 신호가 아닌 프로젝트 내 유사성과 레이블링 지름길에 의존하고 있음을 확인시켜 준다.
• FlakeBench 대조: 모델들은 큐레이션된 FlakeBench 데이터셋에서는 매우 뛰어난 성능(F1 > 0.96)을 보였는데, 이는 테스트 코드가 특정 유형의 플래키성(예: 수정 메시지로부터 인식 가능한 유형)에 대한 분리 가능한 신호를 포함할 수 있음을 시사한다. 그러나 이러한 성공은 C-IDoFT의 광범위한 개발자 확인 플래키성에는 전이되지 않았다.
• FlakeCI 진단: 86개의 플래키 E2E 테스트 분석에서, 저자들은 테스트 코드와 CI 로그를 결합하여 실패 원인을 규명할 수 있는 경우가 42%에 불계하였다. 나머지 58%의 경우, 근본 원인(흔히 네트워크 불안정성, 환경 설정 또는 런타임 상태와 관련됨)을 추가적인 실행 증거 없이는 결정할 수 없었다.

의의 및 주장
본 논문은 기존 문헌에서 보고된 높은 F1 점수가 모델의 플래키 탐지 능력의 증거라기보다는, 벤치마크 구축(특히 fix-commit 지름길)과 평가 프로토콜(교차 검증 데이터 누수 및 프로젝트 중첩)의 산물임을 주장한다.

저자들은 다음과 같이 주장한다:

1. 플래키성은 정적이지 않다: 플래키성은 테스트 코드에 내재된 속성이 아니라 런타임 상호작용으로부터 발생하는 현상이다. 코드만으로 "이 테스트가 플래키한가?"라고 묻는 것은 많은 유형의 플래키성에 대해 부적절한 질문이다.
2. 코드 기반 탐지는 한계에 도달했다: 전통적인 머신러닝을 LLM으로 대체하는 것은 플래키 신호가 소스 코드 자체에 결여되어 있을 수 있다는 근본적인 한계를 극복하지 못한다.
3. 문제의 재정의: 이 분야는 테스트가 플래키한지를 예측하는 것에서, 실행 증거(로그, 스택 트레이스, CI 컨텍스트)를 바탕으로 관찰된 실패가 플래키한 것인지 분류하는 것으로 전환해야 한다.

결론적으로, 본 논문은 코드 기반 탐지기가 재실행으로 확인된 비플래키 레이블을 사용하여 엄격하게 평가되었을 때, 개발자가 확인한 플래키성에 대해 다수 클래스 베이스라인과 구별되지 않는다는 점을 밝힌다. 향후 발전 방향은 정적 코드 분석이 아니라, 실패 수준의 분류 및 실행 환경을 조사하는 에이전트와 같은 실행 기반 접근법에 있다.