Meta'da büyük dil modelleriyle otomatik birim test iyileştirme

Meta'nın Otomatik Birim Test İyileştirme Aracı: TestGen-LLM

• Meta'da geliştirilen TestGen-LLM aracı, büyük dil modellerini (LLM'leri) kullanarak var olan insan tarafından yazılmış testleri otomatik olarak iyileştiriyor.
• TestGen-LLM tarafından oluşturulan test sınıfları, orijinal test setine kıyasla ölçülebilir bir iyileştirme sağlayan ve LLM halüsinasyon sorununu çözen bir dizi filtreyi başarıyla geçiyor.
• Meta'nın Instagram ve Facebook platformları için yapılan test-a-thonlarda TestGen-LLM'in dağıtımını anlatıyor.

TestGen-LLM performans değerlendirmesi

• Instagram'ın Reels ve Stories ürünleri için yapılan değerlendirmede, TestGen-LLM'in test vakalarından %75'i başarıyla derlendi, %57'si güvenilir şekilde geçti ve %25'i kapsamı artırdı.
• Meta'nın Instagram ve Facebook test-a-thonlarında TestGen-LLM, uygulanan tüm sınıfların %11.5'ini iyileştirdi ve Meta yazılım mühendisleri dağıtıma hazırlık için önerilerin %73'ünü kabul etti.
• Bu, LLM tarafından üretilen kodun endüstriyel ölçekte dağıtılmasına ilişkin ilk rapordur ve kod iyileştirmesinde bu düzeyde bir garantiye bu ilk kez sahip olunmasıdır.

GN⁺ Görüşü

• TestGen-LLM, büyük dil modellerini kullanarak mevcut testleri iyileştirerek yazılım testlerinde otomasyon ve kalite iyileştirmesine yenilik getirebilecek bir araçtır.
• Bu araç, gerçek üretim ortamında test kapsamını artırmakta ve güvenilir test vakaları üretmekte başarısız; bu da yazılım mühendisliği topluluğuna önemli bir katkı sağlar.
• Meta'nın test-a-thonlarındaki başarılı uygulanma örnekleri, TestGen-LLM'in gerçek ürün geliştirmeye entegre edilebileceğini gösteriyor ve bu da yazılım geliştirmede verimlilik ile güvenilirliği artırabilecek önemli bir gelişmedir.

[GN⁺]

Hacker News Yorumu

• Bir büyük sigorta şirketinde yöneticiler, tüm kod tabanı için %80 test kapsamı hedefi koymuştu. Bunun üzerine geliştiriciler bu hedefi tutturmak için Java DTO'larının getter ve setter'ları için basit birim testleri yazmaya başladı. Genç bir geliştirici olarak bu deneyim bana, yalnızca KPI'lara odaklanıldığında amaçlanan hedeflerle uyumlu olmayan davranışlar teşvik edilebileceğini gösterdi. Birkaç iyi kurgulanmış E2E senaryosu yazmak yazılım kalitesine çok daha iyi etki yapardı.
• LLM ile üretilen testlerin sorunu, hatalı davranışı "onaylama" olasılığının yüksek olmasıdır. Kod tabanının test kapsamı düşükse bu özellikle belirginleşir. Yeni bir test manuel yazıldığında, sistemin aptalca davrandığını mı yoksa testin yanlış olduğunu mu ortaya koyan bir insan vardır. En azından bu tür testler ayrı bir test klasöründe toplanıp makul bir şüpheyle ele alınmalıdır.
• PDF'ye bakarsanız, bunun yalnızca her seferinde aynı şekilde geçen, yani dalgalanma göstermeyen testler üreten bir yaklaşım olduğunu görürsünüz. Ana amaç, mevcut kod davranışını sabitleyen bir regresyon testi takımı oluşturmaktır. Bu, geliştiricinin yazdığı testleri ikame etmez; geliştiricinin yazdığı testlerin işlevsel gereksinimleri bildiği varsayılır.
• Yaklaşık 20 yıl önce çalıştığım bir şirkette AgitarOne'ı denemiştik. Java kodu için test vakaları otomatik üretip davranışını keşfetmeye yardımcı olacağını vaat ediyordu. Fakat Agitar da otomatik olarak geçen testler üretebildi ve bunlar regresyon süiti olarak kullanılabildi. Kişisel olarak bunu sevmemiştim. Yöneticiler test kapsamı arttığı için kalite de arttı diye düşündü. LLM yaklaşımının Agitar'dan ne kadar daha iyi olduğunu merak ediyorum.
• Test yazımı genel olarak kod kalitesini değerlendirmek için üstün bir yöntemdir. Testler zor veya kapsam sağlamakta zor olanlarsa, test edilen kodun iyileştirilmesi gerekebilir.
• unlogged.io bir süre otomatik junit testleri üretmeye odaklandı. Birkaç nedenle bu yaklaşım başarılı olamadı: 1) Geliştiricilerin sahiplenmek istemediği çok sayıda üretilmiş test kodu, 2) Gerçek dünya senaryolarını simüle etmeyen oluşturulmuş testler, 3) Göstermelik bir gösterge olarak kod kapsamı. Şu anda her benzersiz production senaryosunu simüle eden no-code replay testleri sunmaya odaklanıyoruz. Not: unlogged.io'nun kurucusuyum.
• Aksine yaklaşmak istiyorum. Kabul kriterlerini gir, bunları doğrulayan testleri üret, ardından yalnızca bu testleri geçen kodu üret. Copilot ile bu yaklaşım bazen sınırlı ölçüde mümkün olabiliyor, ama insanların neden buna odaklanmadığını merak ediyorum.
• TestGen-LLM garip bir icattır. Yeniden düzenleme ya da yeniden yazımın ilk adımı olarak iyi olabilir ama makaledeki kod kapsamı vurgusu tamamen bozulmuş. Organizasyon zaten akıl sağlığı yerinde ve yüksek kapsam istiyorsa işe yarayabilir; ancak TestGen-LLM proje kodunu asla iyileştirmeyecek ve gerçek iyileştirmeyi hayata geçirirken sürtünmeyi artıracaktır. Derleyici hatalarına ve başarısız testlere dayanarak LLM çöplüğünü elemek, TestGen-LLM için geçebilir geçmeyebilir edge-case testleri üretmek kadar yararlı olurdu. Makalede üretilen testlerin örnekleri yoksa, bunların gördüğüm diğer LLM tarafından üretilen kodlar kadar amatör olacağına inanıyorum.
• Gelecekte büyük bir otomatik test korpusunu sürdürmenin maliyetini merak ediyorum. Yalnızca vakaları üretmek yerine, onları güncellemenin otomatik bir yolunu da sunmaları gerekiyor.
• Meta çalışanlarının geliştiriciler için yapay zeka konusunda 12 sayfalık bir makale yayınlayıp bunu pazarlamasını ilginç buluyorum. Hatta Sankey diyagramları kullanmışlar. Yanlış olabilir ama böylesi bir sunumda tekrarlanabilir bilgi vermek gerekir. Meta'nın öğreneceği veriye ihtiyacı var. Bu yüzden bir şeyleri açığa çıkarmış olabilirler.
• Instagram'ın Reels ve Stories ürünlerinde yapılan değerlendirmede TestGen-LLM test vakalarının %75'i doğru şekilde inşa edilmiş, %57'si güvenilir biçimde geçmiş, %25'i ise kapsamı artırmış. Sonuç iyi görünmüyor.