- Meta가 2월에 발표한 논문 "Automated Unit Test Improvement using Large Language Models at Meta"에서 TestGen-LLM이라는 도구가 소개됨
- 이 도구는 완전 자동화된 방식으로 테스트 커버리지를 높이는 것이 목적이며, 기존 코드 베이스보다 개선된 것을 보장함
- Meta는 TestGen-LLM 코드를 공개하지 않아서, 오픈소스 Cover Agent의 일부로 직접 구현하기로 결정함
- 여기서는 구현 과정, 발견한 사실, 실제 코드베이스에 TestGen-LLM을 사용할 때 직면한 문제점 등을 공유함
자동 테스트 생성의 기준
- 생성형 AI를 사용한 자동 테스트 생성은 새로운 것이 아님
- 대부분의 LLM은 코드 생성에 능숙하며 테스트 생성도 가능함
- 개발자들이 LLM으로 테스트를 생성할 때 부딪히는 가장 흔한 문제점은 생성된 테스트 대부분이 작동하지 않거나 가치를 더하지 않는다는 것임
- 이를 극복하기 위해 TestGen-LLM 저자들은 회귀 단위 테스트에 대해 다음과 같은 기준을 제시함:
- 테스트가 제대로 컴파일되고 실행되는가?
- 테스트가 코드 커버리지를 높이는가?
- 이 두 가지 기본적인 질문에 답하지 않으면, LLM이 제공한 생성 테스트를 수용하거나 분석할 이유가 없음
- 이 질문을 통과한다면 그 다음 수동 리뷰를 진행
- 테스트는 얼마나 잘 작성되었나?
- 실제로 얼마나 많은 가치를 추가할 수 있나?
- 추가 요구 사항을 충족하는가?
TestGen-LLM의 접근 방식과 보고된 결과
- TestGen-LLM(및 Cover-Agent)은 완전히 헤드리스로 실행됨
- 먼저 많은 테스트를 생성한 다음, 빌드/실행되지 않는 것은 필터링하고 통과하지 않는 것은 버리며, 코드 커버리지를 높이지 않는 것은 폐기함
- 매우 통제된 경우에는 생성된 테스트 대비 모든 단계를 통과하는 비율이 1:4이고, 실제 시나리오에서 Meta 저자들은 1:20 비율을 보고함
- 자동화된 프로세스 후에 Meta는 인간 검토자가 테스트를 수락하거나 거부하도록 함
- 논문 저자들은 최고의 경우 73%의 수용률로 평균 1:2의 수용 비율을 보였다고 함
- 논문에 설명된 대로 TestGen-LLM 도구는 각 실행 시 전문 개발자가 이전에 작성한 기존 테스트 스위트에 추가되는 단일 테스트를 생성함
- 또한 주어진 테스트 스위트에 대해 반드시 테스트를 생성하는 것은 아님
Cover-Agent 구현
- Cover-Agent v0.1은 다음과 같이 구현됨:
- 사용자 입력 받기 (테스트 대상 소스 파일, 개선할 기존 테스트 스위트, 커버리지 보고서, 테스트 스위트 빌드 및 실행 명령, 코드 커버리지 목표 및 최대 반복 실행 횟수, 추가 컨텍스트 및 프롬프트 옵션)
- 동일한 스타일로 더 많은 테스트 생성
- 런타임 환경을 사용하여 해당 테스트 검증 (빌드 및 통과 여부)
- 코드 커버리지 증가와 같은 메트릭을 검토하여 테스트가 가치를 더하는지 확인
- 기존 테스트 스위트 및 커버리지 보고서 업데이트
- 코드가 기준에 도달할 때까지 반복 (코드 커버리지 임계값 도달 또는 최대 반복 횟수 도달)
TestGen-LLM 구현 및 검토 시 직면한 문제점
- 논문에 제시된 예제에서는 공백이 중요하지 않은 Kotlin을 테스트 작성에 사용함
- 반면 Python과 같은 언어에서는 탭과 공백이 중요할 뿐만 아니라 파싱 엔진에 필수적임
- GPT 3.5와 같은 덜 정교한 모델은 명시적으로 프롬프트를 줘도 일관되게 적절하게 들여쓰기된 코드를 반환하지 않음
- 이로 인해 문제가 발생하는 예로는 각 테스트 함수가 들여쓰기되어야 하는 Python으로 작성된 테스트 클래스가 있음
- 이를 개발 수명 주기 전반에 걸쳐 고려해야 했고, 전처리 라이브러리 주변에 더 많은 복잡성이 추가됨
- 이러한 시나리오에서 Cover-Agent를 견고하게 만들기 위해서는 아직 개선해야 할 부분이 많음
- Cover-Agent 흐름의 일부로 사용자가 LLM에 추가 입력이나 지침을 제공할 수 있는 기능 추가함 (
--additional-instructions 옵션)
- 이를 통해 개발자는 프로젝트에 특정한 추가 정보를 제공하여 Cover-Agent를 사용자 정의할 수 있음
- 예를 들어 이 지침을 사용하여 의미 있는 에지 케이스가 있는 풍부한 테스트 세트를 만들도록 Cover-Agent를 유도할 수 있음
- AI 기반 애플리케이션에서 Retrieval-Augmented Generation(RAG)이 더 널리 퍼지는 일반적인 추세에 동의하면서, 단위 테스트 생성과 함께 더 많은 컨텍스트를 갖는 것이 더 높은 품질의 테스트와 더 높은 통과율을 가능하게 한다는 것을 확인함
- 테스트 생성 프로세스를 향상시키기 위해 LLM에 대한 컨텍스트로 추가 라이브러리나 텍스트 기반 설계 문서를 수동으로 추가하려는 사용자를 위해
--included-files 옵션 제공함
- 여러 번의 반복이 필요한 복잡한 코드는 LLM에 또 다른 도전 과제를 제시함
- 실패한(또는 가치를 더하지 않은) 테스트가 생성되면서, 이후 반복에서 동일한 수용되지 않은 테스트가 반복적으로 제안되는 패턴이 발견되기 시작함
- 이를 해결하기 위해 프롬프트에 "실패한 테스트" 섹션을 추가하여 LLM에 해당 피드백을 전달하고 고유한 테스트를 생성하고 사용할 수 없다고 판단한(즉, 깨지거나 커버리지 증가가 부족한) 테스트를 절대 반복하지 않도록 함
- 기존 테스트 스위트를 확장할 때 라이브러리 가져오기를 추가할 수 없다는 점도 이 과정 전반에 걸쳐 제기된 또 다른 문제임
- 개발자는 테스트 생성 프로세스에서 때로는 테스팅 프레임워크에 대한 단일 접근 방식만 사용하는 근시안적일 수 있음
- 많은 다양한 모킹 프레임워크 외에도 다른 라이브러리가 테스트 커버리지 달성에 도움이 될 수 있음
- TestGen-LLM 논문(및 Cover-Agent)은 기존 테스트 스위트를 확장하는 것을 목적으로 하므로 전체 테스트 클래스를 완전히 재구성하는 것은 범위를 벗어남
- 이는 테스트 생성과 대비되는 테스트 확장의 한계이며 향후 반복에서 해결할 계획임
- TestGen-LLM의 접근 방식에서는 각 테스트에 대해 다음 테스트가 제안되기 전에 개발자의 수동 검토가 필요하다는 점을 구분하는 것이 중요함
- 반면 Cover-Agent에서는 커버리지 요구 사항을 달성하거나(또는 최대 반복에서 중지) 프로세스 전반에 걸쳐 수동 개입 없이 가능한 한 많은 테스트를 생성, 검증 및 제안함
- AI를 활용하여 백그라운드에서 실행하여 개발자가 프로세스가 완료된 후 전체 테스트 스위트를 한 번 검토할 수 있는 자동 테스트 생성에 대한 방해받지 않는 접근 방식을 만듦
결론 및 향후 계획
- 많은 사람들(나 자신 포함)이 TestGen-LLM 논문과 도구에 대해 기대하고 있지만, 이 포스트에서는 그 한계에 대해 이야기 했음
- 우리는 여전히 완전히 자동화된 워크플로를 실행하는 AI 팀원이 아니라 AI 어시스턴트 시대에 있다고 생각함
- 동시에 잘 설계된 흐름은 개발자가 자동으로 테스트 후보를 생성하고 훨씬 짧은 시간에 코드 커버리지를 증가시키는 데 도움이 될 수 있으며, 이는 Cover-Agent에서 개발 및 공유할 계획임
- 테스트 생성 도메인과 관련된 최첨단 방법을 지속적으로 개발하여 Cover-Agent 오픈소스 저장소에 통합할 예정임
- 테스팅을 위한 생성형 AI에 관심 있는 모든 사람이 협업하고 Cover Agent의 기능 확장에 도움을 주기를 바라며, 이 오픈소스 도구를 활용하여 새로운 테스트 생성 기술을 탐구하도록 연구자들에게 영감을 주기를 희망함
- GitHub의 오픈소스 Cover-Agent 저장소에 개발 로드맵을 추가했으며, 로드맵에 따라 또는 여러분 자신의 아이디어에 따라 저장소에 기여하는 모습을 보고 싶음
- Cover-Agent의 비전은 향후 모든 pre/post-pull 요청에 대해 자동으로 실행되고, 작동하고 코드 커버리지를 높이는 것으로 검증된 회귀 테스트 개선 사항을 자동으로 제안하는 것
- Cover-Agent가 코드베이스를 자동으로 스캔하고 테스트 스위트로 PR을 여는 것을 상상함
- AI를 활용하여 우리가 좋아하지 않는 작업을 더 효율적으로 처리해봐요!