GN⁺: 메타에서 대규모 언어 모델을 활용한 자동화된 단위 테스트 개선
(arxiv.org)메타의 자동화된 단위 테스트 개선 도구: TestGen-LLM
- 메타에서 개발한 TestGen-LLM 도구는 대규모 언어 모델(LLMs)을 사용하여 기존의 인간이 작성한 테스트를 자동으로 개선함.
- TestGen-LLM이 생성한 테스트 클래스는 원래 테스트 스위트에 비해 측정 가능한 개선을 보장하는 일련의 필터를 성공적으로 통과하여 LLM 환각 문제를 해결함.
- 메타의 Instagram과 Facebook 플랫폼을 위한 테스트 대회(test-a-thons)에서 TestGen-LLM의 배포를 설명함.
TestGen-LLM의 성능 평가
- Instagram의 Reels와 Stories 제품에 대한 평가에서 TestGen-LLM의 테스트 케이스 중 75%가 정확하게 빌드되었고, 57%가 신뢰성 있게 통과했으며, 25%가 커버리지를 증가시킴.
- 메타의 Instagram과 Facebook 테스트 대회에서 TestGen-LLM은 적용된 모든 클래스의 11.5%를 개선했으며, 메타 소프트웨어 엔지니어들이 제작 배포를 위해 73%의 권장 사항을 수락함.
- 이는 LLM이 생성한 코드의 산업 규모 배포에 대한 첫 번째 보고서이며, 코드 개선에 대한 이러한 보증을 받은 것임.
GN⁺의 의견
- TestGen-LLM은 소프트웨어 테스트의 자동화와 품질 향상에 혁신을 가져올 수 있는 도구로, 대규모 언어 모델을 활용하여 기존 테스트를 개선하는 데 성공함.
- 이 도구는 실제 산업 환경에서 테스트 커버리지를 증가시키고, 신뢰성 있는 테스트 케이스를 생성하여 소프트웨어 엔지니어링 커뮤니티에 중요한 기여를 함.
- 메타의 테스트 대회에서의 성공적인 적용 사례는 TestGen-LLM이 실제 제품 개발에 통합될 수 있는 가능성을 보여주며, 이는 소프트웨어 개발의 효율성과 안정성을 향상시킬 수 있는 중요한 발전임.
Hacker News 의견
- 한 대형 보험회사에서 관리자들은 전체 코드베이스에 대해 80%의 테스트 커버리지 목표를 설정했음. 이에 개발자들은 목표 달성을 위해 자바 DTO의 게터와 세터에 대한 단순한 유닛 테스트를 작성하기 시작했음. 젊은 개발자로서, 이 경험은 KPI에만 집중하면 의도된 목표와 일치하지 않는 행동을 유도할 수 있다는 것을 깨닫게 해줌. 몇 가지 잘 고안된 E2E 테스트 시나리오가 소프트웨어 품질에 더 좋은 영향을 미쳤을 것임.
- LLM 생성 테스트의 문제점은 버그가 있는 동작을 "승인"할 가능성이 높다는 것임. 코드베이스의 테스트 커버리지가 낮은 경우 특히 그럴 가능성이 있음. 수작업으로 새 테스트를 작성할 때는 시스템이 멍청한 것인지 테스트가 잘못된 것인지 판단할 수 있는 사람이 있음. 최소한 이러한 테스트들은 특별한 테스트 폴더에 분리되어 적절한 수준의 의심으로 다뤄져야 함.
- PDF를 읽어보면 이것은 단지 반복적으로 통과하는 즉, 변덕스럽지 않은 테스트를 생성하는 것으로 보임. 주 목적은 기존 코드의 동작을 고정시키는 회귀 테스트 스위트를 만드는 것임. 이것은 개발자가 작성한 테스트를 대체하는 것이 아니며, 개발자가 작성한 테스트는 기능 요구 사항을 알고 있다고 기대함.
- 약 20년 전에 근무했던 회사에서는 AgitarOne을 시험해봤음. 이는 자바 코드에 대한 테스트 케이스를 자동으로 생성하여 그 동작을 탐색하는 데 도움을 주겠다고 약속했음. 하지만 Agitar는 또한 자동으로 통과하는 테스트를 생성할 수 있었고, 이를 회귀 스위트로 사용할 수 있었음. 개인적으로는 이를 좋아하지 않았음. 관리자들은 테스트 커버리지가 증가했으니 품질도 향상되었다고 생각했음. LLM 접근 방식이 Agitar에 비해 얼마나 더 나은지 궁금함.
- 테스트 작성은 일반적으로 코드 품질을 판단하는 뛰어난 방법임. 테스트가 복잡하거나 커버리지 달성이 어렵다면, 테스트 대상 코드에 개선이 필요할 가능성이 높음.
- unlogged.io에서는 한동안 자동으로 junit 테스트를 생성하는 데 주력했음. 몇 가지 이유로 인해 이 접근법은 성공하지 못했음: 1) 개발자들이 유지 관리하고 싶어하지 않는 많은 생성된 테스트 코드, 2) 실제 세계 시나리오를 시뮬레이션하지 않는 생성된 테스트, 3) 허영 지표로서의 코드 커버리지. 현재는 모든 고유한 프로덕션 시나리오를 시뮬레이션하는 노코드 리플레이 테스트를 제공하는 데 집중하고 있음. 참고로 unlogged.io의 창립자임.
- 반대로 접근하고 싶음. 수용 기준을 입력하고, 그것을 확인하는 테스트를 생성한 다음, 테스트를 통과하는 코드만 생성하게 하고 싶음. Copilot을 사용하면 때때로 제한적인 방식으로 이에 가까워질 수 있지만, 왜 이 방식으로 집중하는 사람이 없는 것 같은지 의문임.
- TestGen-LLM은 이상한 창조물임. 리팩토링이나 재작성의 첫 단계로 사용될 수 있다고 생각하지만, 논문에서 코드 커버리지에 대한 강조는 완전히 뇌가 깨진 것 같음. 조직이 이미 뇌가 깨져서 높은 커버리지를 요구한다면 좋을 수 있지만, TestGen-LLM은 프로젝트의 코드를 어떤 방식으로도 개선하지 않을 것이며, 실제 개선을 구현하는 데 관련된 마찰을 증가시킬 것임. 컴파일러 오류와 실패한 테스트에 의존하여 LLM 쓰레기를 걸러내는 TestGen-LLM은 통과할 수도 있고 통과하지 않을 수도 있는 엣지 케이스 테스트를 생성하는 것이 훨씬 유용할 것임. 논문에 생성된 테스트의 예가 없어서, 그것들이 내가 본 나머지 LLM 생성 코드와 같은 아마추어 같다고 의심함.
- 미래에 거대한 자동 생성된 테스트 코퍼스를 유지하는 데 드는 비용이 얼마나 될지 궁금함. 케이스를 생성하는 것뿐만 아니라 업데이트하는 자동화된 방법도 제공해야 함.
- 메타 직원들이 개발자를 위한 AI를 홍보하기 위해 12페이지짜리 논문을 발표한 것이 흥미롭다고 인정함. 심지어 산키 다이어그램까지 사용함. 아마 틀렸을 수도 있지만, 이런 식으로 발표된다면 재현할 수 있는 정보를 제공해야 하지 않을까? 메타가 학습할 수 있는 데이터가 필요함. 그래서 무언가를 공개했을 수도 있음.
- Instagram의 Reels와 Stories 제품에 대한 평가에서 TestGen-LLM의 테스트 케이스 중 75%가 올바르게 구축되었고, 57%가 신뢰성 있게 통과했으며, 25%가 커버리지를 증가시켰음. 그 결과가 그다지 좋지 않은 것 같음?