한 대형 보험회사에서 관리자들은 전체 코드베이스에 대해 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%가 커버리지를 증가시켰음. 그 결과가 그다지 좋지 않은 것 같음?
Hacker News 의견