TestMap: Evidence Infrastructure for Foundation-Model-Assisted Test Generation

기술 요약: TestMap – 파운데이션 모델 지원 테스트 생성을 위한 증거 인프라

문제 정의
파운데이션 모델(FM)은 그럴듯한 유닛 테스트를 생성하는 데 점점 더 능숙해지고 있으나, 생성된 테스트의 정확성, 유용성, 유지보수성 및 통합 가치를 판단하는 것은 여전히 중대한 과제로 남아 있다. 핵심 문제는 "재귀적 검증(recursive validation)" 이슈이다. 생성된 테스트는 코드 산출물인 동시에 검증 산출물이기도 하다. 즉, 테스트가 테스트 대상 시스템(System Under Test)을 검증하기 전에 먼저 검증되어야 한다. 현재 검증 프로세스는 파편화된 도구들(빌드 시스템, 테스트 러너, 커버리지 도구, 뮤테이션 도구, 정적 분석기)에 흩어져 있으며, 개별 테스트 후보와 증거를 연결하기보다는 주로 집계된 결과만을 보고한다. 또한, 기존 방식들은 실패하거나 중간 단계에 있는 후보들을 빈번하게 폐기함으로써 모델의 한계, 컨텍스트 부족, 또는 테스트 대상 시스템의 잠재적 결함에 관한 귀중한 데이터를 손실한다.

방법론: TestMap 인프라
본 논문은 C#/.NET 리포지토리를 구체적인 대상으로 하여, 증거 기반의 FM 지원 테스트 생성 및 평가를 자동화하기 위해 설계된 오픈 소스 인프라 프로토타입인 TestMap을 제시한다. TestMap은 생성된 테스트를 최종 정답이 아닌 "후보(candidates)"로 취급하며, 이들의 전체 라이프사이클을 기록한다.

시스템은 다음과 같은 구조화된 파이프라인을 통해 작동한다:

1. 리포지토리 인입 및 정적 분석: TestMap은 대상 리포지토리를 클론하고, Roslyn API를 사용하여 솔루션을 파싱하며, 소스 코드, 의존성 및 테스트 구조를 매핑하는 정적 분석을 수행한다. 또한 코드 메트릭을 수집하고 테스트 스멜(xNose의 커스텀 버전 사용)을 탐지한다.
2. 베이스라인 실행: 생성 전, 기존 테스트 스위트를 실행하여 커버리지, 뮤테이션 점수 및 실행 결과에 대한 베이스라인을 구축한다.
3. 대상 선택 및 컨텍스트 구성: 생성 대상(예: 미커버 라인, 생존한 뮤턴트 또는 관련 테스트)을 구성 가능한 기준에 따라 선택한다. "증거 패키지(evidence package)"는 대상 코드, 관련 테스트, 커버리지 격차, 프레임워크 컨벤션을 포함하여 구성된다.
4. 모델 가이드 생성: TestMap은 단일 프롬프트 생성 대신 분해된 생성 파이프라인(RUG에서 영감을 받음)을 채택한다. 이는 작업을 계획 단계(시나리오 계획, 메서드 명명, 세팅(arrangement), 입력 계획, 액션 계획, 단언(assertion) 계획)로 나눈 후 최종 합성으로 이어지게 한다. 또한 다양한 컨텍스트 모드(NoHistory 대 ChainedHistory)와 pass@k 예산을 지원한다.
5. 검증 및 복구: 생성된 후보들은 사전 실행 검증(구문 추출, 삽입, 컴파일러 진단)과 사후 실행 검증(빌드, 실행, 커버리지, 뮤테이션)을 거친다. 실패한 후보는 폐기되지 않고 진단 데이터와 함께 보존된다. 활성화된 경우, 복구 루프는 컴파일 에러, 실행 로그, 단언 실패를 사용하여 모델에 수정을 요청한다.
6. 증거 지속성: 프롬프트, 모델 응답, 빌드 로그, 실행 결과, 커버리지 변화량, 뮤테이션 결과 및 복구 이력을 포함한 모든 산출물은 SQLite 데이터베이스에 저장된다. 이를 통해 개별 후보에 대한 세밀한 분석과 전략 간의 집계된 비교가 가능하다.

주요 기여
본 논문의 기여는 다음과 같다:

1. 문제 프레이밍: FM 지원 테스트 생성을 생성된 테스트가 증거로서 역할을 하기 전에 반드시 검증되어야 하는 재귀적 검증 문제로 정의하였다.
2. TestMap 프로토타입: 리포지토리 분석, 후보 검증, 증거 수집, 복구 추적 및 실험 로깅을 자동화하는 오픈 소스 증거 인프라를 도입하였다.
3. 라이프사이클 보존: 실패, 복구, 낮은 영향력 및 증거 긍정 결과를 포함하여 후보의 전체 라이프사이클을 보존함으로써 중간 결과에 대한 연구를 가능하게 한다.
4. 리포지토리 특화 실험: 표준화된 벤치마크를 넘어, 실제 코드베이스에서 모델, 프롬프트, 생성 전략 및 복구 워크플로우를 비교하는 실험을 용이하게 한다.
5. 증거 모델: 후보를 리포지토리 컨텍스트, 생성 파라미터, 실행 결과 및 품질 지표와 연결하는 구조화된 증거 모델을 정의한다.

결과 및 발견
본 논문은 양적인 성능 지표(예: "TestMap이 커버리지를 X% 향상시켰다")를 포함한 대규모 경험적 연구를 제시하지 않는다. 대신, 인프라의 다음과 같은 역량을 입증하는 데 집중한다:

• 실제 C#/.NET 리포지토리를 성공적으로 인입하고 분석함.
• 빌드 실패 및 실행 에러 처리를 포함한 전체 생성-검증 파이프라인을 실행함.
• ValidationFailed, Validated, ValidatedLowImpact, ValidatedEvidencePositive 결과를 구분하여 상세한 후보 이력을 지속함.
• 생성 전략(예: 단순 프롬프팅 대 메트릭 기반 프롬프팅)에 대한 리포지토리별 비교를 지원함.

저자들은 생성된 테스트가 종종 복구를 필요로 하며, 실패한 후보가 오라클 품질, 컨텍스트 격차, 툴체인 비효율성에 관한 중요한 증거를 제공한다는 점을 밝힌다.

의의 및 주장
본 논문은 TestMap이 소프트웨어 공학의 중요한 인프라 격차를 해결한다고 주장한다. TestMap의 의의는 단순히 실행 가능한 테스트를 생성하는 것을 넘어, 생성된 테스트를 관찰 가능하고, 반복 가능하며, 비교 가능하게 만드는 데 있다.

• 벤치마크를 넘어: TestMap은 특정 리포지토리의 실제 제약 조건(빌드 시스템, 의dependency, 기존 테스트 스타일) 하에서 FM 지원 생성이 어떻게 동작하는지에 대한 증거를 제공함으로써 표준화된 벤치마크를 보완한다.
• 의사결정을 위한 증거: 실패 및 복구된 후보를 보존함으로써, 개발자의 검토와 경험적 분석을 지원하며, 모델의 한계, 툴체인 문제, 실제 시스템 결함을 구분할 수 있도록 돕는다.
• 향러 방향: 저자들은 FM 지원 테스트의 미래는 단순히 테스트를 생성하는 것이 아니라, 해당 테스트가 유용하고 유지보수 가능하며 신뢰할 수 있는지 결정하는 데 필요한 증거를 제공하는 인프라가 필요하다고 결론짓는다. TestMap은 단언 품질, 플래키니스(flakiness), 메트릭 귀속, 개발자 수용성과 같은 도전 과제를 인정하면서, 이러한 증거 인프라를 향한 단계로 제시된다.

본 논문은 현재의 프로토타입이 개발자의 결정이나 신뢰도 교정(trust calibration) 개선을 직접 연구하는 것이 아니라, 그러한 미래 연구에 필요한 데이터 인프라를 제공하는 것임을 명시하며 겸허한 어조를 유지한다.