기술 요약: Java SWE 이슈를 위한 재현 테스트 생성

문제 제기

본 논문은 Java 자동화 소프트웨어 공학 (SWE) 에서의 중요한 간극인 재현 테스트 생성 문제를 다룹니다. 재현 테스트는 현재 코드베이스에서 실패하여 (이슈의 존재 확인) 이슈가 수정된 후에는 통과하는 (이슈의 부재 확인) 테스트로 정의됩니다. 최근 진보로 Python 을 위한 벤치마크와 솔루션이 등장했지만, 기업용 소프트웨어에서 지배적인 위치를 차지하는 Java 는 여전히 소외되어 있습니다. 기존 Java 중심 도구들은 결함 국소화 기능이 부족하거나, 단순화된 문제 변형에 의존하거나, 데이터셋 오염과 과적합으로 고통받고 있습니다. 또한, 기업용 Java 버그는 종종 오픈소스 Python 버그와 분포와 복잡성 측면에서 다르므로, Java 의 정적 타입 시스템과 객체지향적 특성을 고려한 전문화된 접근 방식이 필요합니다.

방법론

저자들은 최첨단 Python 재현 테스트 생성기를 기반으로 한 **Java 용 e-Otter++**를 제안합니다. 이 방법론은 생성 과정에서 수정 코드 ($c_{new}$) 에 접근할 필요 없이 리포지토리 수준의 복잡성을 처리하도록 설계된 다단계 파이프라인입니다.

1. 파이프라인 아키텍처

워크플로우는 네 가지 주요 구성 요소로 이루어집니다:

• 로컬라이저 (Localizer): "초점 함수 (focal functions)" (수정될 가능성이 높은 함수) 와 관련 회귀 테스트를 식별합니다. Python 버전에서는 이러한 작업을 분리했으나, Java 프로젝트에서 새로운 테스트 파일의 빈도가 더 높기 때문에 Java 버전에서는 이를 단일 단계로 통합했습니다. 이는 이름으로 관련 파일 선택, 이름으로 함수 선택, 그리고 마지막으로 함수 본문을 기반으로 필터링하는 3 단계 LLM 프로세스를 사용합니다.
• 컨텍스트화기 (Contextualizer): Java 에 공통적으로 나타나는 새로운 테스트 파일에 필요한 스캐폴딩을 구성합니다. 이는 리포지토리를 쿼리하고 기존 옵션 중에서 선택하여 패키지 이름, 임포트, 파일 경로를 결정함으로써 환각을 최소화합니다.
• 초기 테스트 생성기 (Initial Test Generator): 이슈 설명과 국소화된 컨텍스트를 프롬프트로 받아 새로운 파일의 새로운 클래스로서 초기 테스트 후보 ($t_{ot}$) 를 생성합니다.
• 정제기 (Refiner): 실행 피드백을 사용하여 테스트를 반복적으로 개선합니다. 이는 구식 코드 ($c_{old}$) 에서 테스트를 실행하고, LLM 기반 비판가를 통해 로그를 분석한 후, 테스트가 잘못된 이유로 실패할 경우 테스트를 다시 작성합니다. 이 루프는 최대 10 회 실행되어 반복적인 오류를 방지하기 위해 변경 사항을 누적합니다.

2. 이질적 프롬프팅을 통한 추론 확장

테스트 후보의 다양성을 높이기 위해 시스템은 온도 기반 샘플링 대신 **이질적 프롬프팅 (heterogeneous prompting)**을 사용합니다. 이슈 설명은 여섯 가지 다른 변형 (morph) 으로 재작성됩니다:

• Standard (표준): 구조화된 형식으로 재작성.
• Simple (단순): 전문 용어를 제거하고 텍스트를 단순화.
• dropCode: 오해의 소지가 있는 코드 스니펫 제거.
• initTest: 생성된 초기 테스트를 프롬프트에 포함.
• initPatch: 제안된 코드 패치를 프롬프트에 포함.
• Default (기본): 원래 이슈 설명 사용.

이후 **테스트 선택기 (Test Selector)**는 여섯 가지 결과 후보 (그리고 해당 실행 로그) 를 평가하여 제출할 단일 최상의 테스트를 선택합니다.

주요 기여

1. TDD-Bench-Java: Java 재현 테스트 생성을 위한 최초의 리포지토리 수준 벤치마크입니다. 이는 인기 있는 오픈소스 리포지토리 (예: Trino, Jackson, RocketMQ) 에서 유래한 250 개의 인스턴스로 구성되며, "실패에서 통과 (fail-to-pass)" 행동을 보장하도록 필터링되었습니다. 데이터셋에는 다양한 빌드 도구 (Maven, Gradle) 와 프로젝트 구조가 포함됩니다.
2. Java 용 e-Otter++: Python 워크플로우에서 적응된 강력한 솔루션으로, 새로운 벤치마크에서 높은 성능을 달성했습니다. 이는 결함 국소화를 포함하는 리포지토리 수준 Java 재현 테스트 생성을 위한 최초의 완전한 솔루션입니다.
3. 독점 산업 평가: 본 논문은 내부 IBM Java 프로젝트의 150 개 이슈로 구성된 오염 없는 독점 데이터셋에서 시스템을 평가합니다. 이는 오픈소스 데이터와 크게 다른 실제 기업용 코드에 이러한 모델을 적용하는 데 따른 과제를 통찰하게 해줍니다.

결과

공개 벤치마크 (TDD-Bench-Java)

Claude-Sonnet-4.5 및 GPT-5.2 모델을 사용하여 e-Otter++ 는 다음과 같은 결과를 달성했습니다:

• **43.6%**의 실패 - 통과율 (Claude-Sonnet-4.5 사용).
• **46.4%**의 실패 - 통과율 (GPT-5.2 사용).

주요 발견 사항:

• 정제 영향: 정제 단계 (e-Otter) 는 초기 생성기 (Otter) 에 비해 성능을 크게 향상시켰으며, 모델과 변형에 따라 상대적 개선폭이 26.2% 에서 64.3% 까지 다양했습니다.
• 이질적 프롬프팅: 여섯 가지 변형을 사용하면 단일 변형 접근 방식에 비해 N=6 (적어도 하나의 후보가 성공함) 에서 실패 - 통과율이 32% 이상 증가했습니다.
• 통계적 유의성: McNemar 검정은 Otter 에서 e-Otter 로의 개선이 통계적으로 유의미함을 확인했습니다 ($p < 0.01$).

독점 데이터셋 결과

내부 IBM 데이터셋에서의 성능은 기업용 코드의 어려움을 부각시켰습니다:

• 기본 성능: 기본 이슈 설명을 사용할 때 실패 - 통과율은 불과 4% (6/150) 였습니다.
• 힌트 제공 시: 시스템에 코드 패치에서 파생된 새로운 클래스 이름과 함수 시그니처인 "힌트"를 제공했을 때, 해당 비율은 20% (30/150) 로 향상되었습니다.
• 데이터 특성: 독점 이슈는 더 짧았으며, 코드 스니펫이 부족했고, 훨씬 더 큰 코드 패치 (공개 데이터의 평균 55 줄 대비 평균 362 줄) 를 포함했습니다. 또한, 독점 이슈의 84% 는 버그 수정이 아닌 기능 요청이었으며, 종종 모델이 예측하기 어려운 새로운 파일을 도입했습니다.

중요성과 주장

본 논문은 다음과 같은 방식으로 해당 분야에 중요한 기여를 한다고 주장합니다:

1. 언어 간극 해소: 기업용 소프트웨어에 필수적이지만 재현 테스트 생성 연구에서 과거에 소외되었던 Java 를 위한 최초의 전용 벤치마크와 솔루션을 제공합니다.
2. 산업 관련성: 오픈소스 벤치마크를 넘어 독점 데이터에서의 성능을 평가함으로써, 모델이 선별된 공개 데이터에서는 잘 작동하지만 실제 기업용 이슈의 "노이즈"와 복잡성 (예: 짧은 설명, 새로운 파일 생성) 에서는 상당한 어려움을 겪는다는 점을 드러냈습니다.
3. 방법론적 엄밀성: 이질적 프롬프팅을 통한 추론 확장과 실행 주도 정제가 Java 에서 효과적인 전략임을 입증했습니다. 이는 정적 타입 시스템이 Python 의 런타임 오류와 다른 빌드 시간 오류를 유발함에도 불구하고 유효함을 보여줍니다.

저자들은 현재 LLM 기반 접근 방식이 유망함을 보여주지만, Java 소프트웨어 개발에 신뢰할 수 있는 진단과 검증을 도입하려면 특히 poorly specified 이슈 처리와 새로운 코드 구조에 대한 정확한 컨텍스트 생성 측면에서 더 많은 혁신이 필요하다고 결론지었습니다.