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.
1 yorum
Hacker News yorumları
Eskiden çalıştığım büyük bir sigorta şirketinde yönetim, tüm kod tabanı için %80 test kapsamı hedefi koymuştu; insanlar da hedefi tutturmak için Java DTO’larının getter/setter’ları için işe yaramaz birim testleri yazmaya başladı.
Elbette geliştiriciler Sonar’ın kapsam ölçüm kurallarını da değiştiremiyordu; genç bir geliştiriciyken, yalnızca KPI’lara bakmanın asıl niyetle uyuşmayan davranışları teşvik edebileceğini öğrendim.
İyi tasarlanmış birkaç E2E test senaryosu yazılım kalitesi açısından muhtemelen daha iyi olurdu.
Sorun, dağınık eski kodun %95 kapsam ile çok iyi test edilmiş olmasıydı. Yeni kod %100 kapsamlıydı ama çok daha kısa olduğu için toplam kapsam aksine düştü ve geçemedi.
Geriye yalnızca test etmesi zor ve test etmenin pek anlamı olmayan Swing UI kodu kaldığından, geliştirme lideri Swing testleri yazmak için 1-2 hafta harcamak yerine eski kodu deponun bir yerinde bırakıp testleri sadece o kodu gösterecek şekilde ayarladı.
Sonuçta üretimde asla çağrılmayan binlerce satır ölü kod, Sonar’ı memnun etmek için depoda kaldı.
Sonuç, header’da
static const unsigned ONE = 1;,TWO = 2;,THREE = 3;gibi sabitlerin binlercesinin oluşmasıydı.https://en.m.wikipedia.org/wiki/Mutation_testing
Neredeyse her dil için araçlar ve framework’ler var; örneğin stryker-mutator(C#, TypeScript), pitest(Java), mutatest(Python).
6 yıllık kariyerimde bu kadar kötü yazılmış bir uygulamayı ilk kez görüyordum; sadece stil değil, fiilen tamamen bozuk pek çok kısım da vardı ama kimse neyin yanlış olduğunu bilmiyordu.
Sonar’dan gerçekten nefret ediyorum. Sadece güvenlik açığı raporlamak için kullanılmalı; değişken adını değiştir dememeli ya da “bu kod tekrarını refactor etmelisin” diye konuşmamalı. Zaten Jira ticket backlog’u var; neyi ne zaman yapmam gerektiğini de söylemesin.
Ama yöneticiler bu tür yetki oyunu araçlarını çok seviyor.
Büyük sorun, bunu zorunlu kılıp aptallıktan kaçınmak için devasa bir bürokratik süreçten geçmeyi şart koşmaları. Daha geçen hafta zorunlu kod kalitesi aracı,
res.status(200).json()içinde HSTS header’ı yok diye şikâyet ettiği için uğraştım.Elle ayarlasam da,
app.use(helmet())kullansam da şikâyet etmeye devam etti; sonunda sanki tüm backend’i tek bir dosyada yazmamı istiyor gibi görünüyordu. Oysa HSTS ingress veya load balancer’da çok daha zarif ve otomatik şekilde ele alınır.Bunu yanlış pozitif olarak işaretleyip üst yöneticiye HSTS’nin ne olduğunu açıklayarak onay almak için 1-2 hafta harcayabilirdim; ama sonunda response nesnesi prototipine
res.sendJson(data, status = 200)ekledim. Kesinlikle aptalca bir implementasyon, ama bürokrasinin yoğun olduğu alanlarda kötü yazılımların bu tür kötü implementasyonların toplamıyla ortaya çıktığını fark etmemi sağladı.“TestGen-LLM test vakalarının %75’i sorunsuz derlendi, %57’si kararlı biçimde geçti ve %25’i kapsamı artırdı” kısmına bakınca sorun şu gibi görünüyor: LLM tarafından üretilen testlerin, hatalı davranışı “onaylama” olasılığı yüksek
Özellikle test kapsamı zaten düşük olan bir kod tabanında bu daha da olası. Bir insan doğrudan yeni test yazdığında, sistemin mi aptalca davrandığını yoksa testin mi yanlış olduğunu değerlendirecek birinin olması gibi bir avantaj var
En azından bu tür testler özel bir test klasöründe ayrılmalı ve uygun düzeyde şüpheyle ele alınmalı
Ancak kapsamı iyi olan bir kod tabanı, büyük ölçekli yeniden düzenlemelerin regresyon olmadan güvenle yapılmasını sağlar; kodda hata olsa ve yeniden düzenleme o hatayı aynen korusa bile bu yararlı bir özelliktir
Mevcut davranışı kodlamak üzere tasarlanmış bir test üretme aracının riski, aslında yalnızca mevcut davranışı kodlamışken sahte bir güven hissine kapılabilmektir
Belki de böyle şeylere “test” demek yerine “davranış anlık görüntüsü” gibi bir ad verilirse sorun çözülebilir. Doğru davranışı değil, mevcut davranışı yakaladığını ifade etmesi gerekir
Bu yüzden hangi senaryonun gerçekleştiğini anlamak için her zaman belli ölçüde insan gözetimi gerektiğini düşünüyorum
Bu tür şeyler her çeşit sistemde olur ve insanlar, burada olduğu gibi bir otomasyon katmanı daha eklemenin bunu çözeceğini düşünme eğilimindedir. Testler başlangıçta programın doğru çalıştığını doğrulamak için icat edildi; onu da otomatikleştirince aynı problemle, bu kez assertion yerine test biçiminde, daha büyük kod olarak yeniden karşılaşıyoruz
Test için gereken yan girdilere yönelik factory’leri nasıl oluşturacağını bilmeyebilirsin, ama kodun kendisinin nasıl çalışması gerektiğini biliyor olabilirsin
LLM test iskeletini çıkarıp geliştiricinin iş mantığı doğrulamalarını kolayca yazmasını sağlarsa bu büyük bir kazanç olabilir
Ancak üretilen testler çoğu birim test gibi uygulamaya aşırı bağlıysa geliştirme hızını yavaşlatır. Tek tek testleri düzeltmek çok zorsa, büyük değişikliklerde insanların tüm testleri silip yeniden ürettiğini bile görebiliriz
Kodun bir kısmı o hataya bağımlı olabilir ve bunu ister kazara ister kasıtlı olarak düzeltmek daha ciddi sorunlara yol açabilir
Elbette bu tür testler gerçek gereksinimleri doğrulayan testlerin yerini tutamaz
Ancak düşük kapsamla bakım moduna girmiş sayısız legacy sistem var ve bu durumlarda mevcut davranışı doğrulayan testler üretmek çok yararlı. Birisi değişiklik yaptığında geri kalan her şeyin aynı kalıp kalmadığını kontrol etmeyi sağlar
PDF’yi okuyunca bunun “sadece” tekrar tekrar geçen, yani flaky olmayan testler üretmek olduğu anlaşılıyor
Ana amaç, mevcut kodun davranışını sabitleyen testlerle bir regresyon testi paketi oluşturmak; işlevsel gereksinimleri bilerek yazan geliştirici testlerinin yerine geçmek değil
Neredeyse 20 yıl önce çalıştığım şirkette de AgitarOne’ı denemiştik; Java kodunun davranışını keşfeden test vakalarını otomatik üreteceğini vaat ediyordu. Ayrıca geçen testleri neredeyse otomatik biçimde oluşturup regresyon testi paketi olarak kullanabiliyordun
Şahsen hoşlanmamıştım. Ortaya çok fazla şey çıkıyordu ve yönetim kapsam artarsa kalitenin de artacağını düşünüyordu. FB’nin burada bahsettiği LLM yaklaşımının o zamankinden ne kadar iyi olduğunu merak ediyorum
http://www.agitar.com/solutions/products/agitarone.html
LLM, iyi testlerin geçtiği varsayımına ya da oracle’a dayanmadan gerçek doğruluğu değerlendirebilir hale gelene kadar buraya ulaşmak zor görünüyor. Prompt’a bir şekilde davranış beklentilerini dahil etmek gerekecektir
Testlerin değeri, birilerinin önemsediği şeylerin bozulmamasını güvenceye almaktır; belirli bir implementasyonun ürünü olan, neredeyse hiç kullanılmayan her edge case davranışını sonsuza kadar sabitlemek değil
Deneyimlerime göre test yazmak genellikle kod kalitesini değerlendirmek için harika bir yöntemdir
Testler karmaşıksa veya kapsam elde etmek zorsa, test edilen kodun iyileştirilmesi gerekme olasılığı yüksektir
Düşük bağlılık, yüksek uyumluluk ve düşük karmaşıklığa sahip kodun birim testinin yazılması kolay olmalıdır
Instagram’ın Reels ve Stories ürün değerlendirmesinde TestGen-LLM test vakalarının %75’inin sorunsuz derlendiği, %57’sinin kararlı biçimde geçtiği ve %25’inin kapsamı artırdığı söyleniyor
Meta’nın Instagram ve Facebook test etkinliğinde, uygulanan tüm sınıfların %11,5’inin iyileştirildiği ve önerilerin %73’ünün Meta yazılım mühendisleri tarafından production’a dağıtım için onaylandığı belirtiliyor
Bunun iyi bir oran olup olmadığını bilmiyorum. Kabul edilemeyenlerin kod incelemesinde yakaladığımız önemsiz hatalar mı yoksa ciddi sorunlar mı olduğunu anlamak için daha fazla okumak gerekir. Başarısızlık oranı %25 olan bir insan mühendis, başarısızlık türüne bağlı olarak pek yardımcı olmayabilir
Android kodu için birim test üretimini otomatikleştirme yönündeki genel görevin de doğru yön olup olmadığını sorguluyorum. TDD tarafındaki insanlar mezarlarında, ya da evlerindeki yataklarında, dönüp duruyor olabilir. Yine de muhtemelen arkaya bir çekince koymuşlardır
unlogged.io’da bir süre ana odak JUnit testlerinin otomatik üretilmesiydi, ancak birkaç nedenden dolayı pek tutmadı.
Üretilen test kodu çok fazlaydı; geliştiriciler bunları bakımını yapmak istemedi, gerçek senaryoları simüle edemedi ve kod kapsamı bir gösteriş metriğiydi. Geliştiriciler, anlamsız senaryolarla hedefi tutturmanın dolambaçlı yollarını buldu.
Şimdi tüm benzersiz operasyon senaryolarını simüle eden ve geliştiricinin dış bağımlılıkları mock’layarak yerelde yeniden oynatabileceği kodsuz replay testleri sunmak için çalışıyoruz.
Bu arada unlogged.io’nun kurucusuyum.
Ters yönde gitmek istiyorum. Kabul kriterlerini girdi olarak verince bunları doğrulayan testlerin üretilmesini, ardından da testleri geçen kodun üretilmesini istiyorum.
Copilot ile sınırlı ölçüde, ara sıra buna benzer şeyler yapılabiliyor; ama neden kimsenin bu sıraya odaklanmıyor gibi göründüğünü bilmiyorum.
TestGen-LLM gerçekten tuhaf bir ürün. Refaktör etmenin ya da yeniden yazmanın ilk adımı olarak kullanılabilir gibi görünüyor, ama makalede kod kapsamına vurgu yapılması bana karar mekanizmasının tamamen bozulduğu izlenimini veriyor.
Kuruluş zaten yüksek kapsam zorunluluğuyla bozulmuşsa iyi olabilir; ama TestGen-LLM proje kodunu hiçbir şekilde daha iyi hâle getirmeyecek, yalnızca gerçek iyileştirmeleri uygulamanın sürtünmesini artıracaktır.
Geçip geçmeyebilecek uç durum testleri üretmek çok daha faydalı olurdu; oysa TestGen-LLM, LLM çöpünü derleme hataları ve başarısız testlerle ayıklamaya dayanıyor.
Makalede üretilmiş test örneklerinin hiç olmamasına bakınca, şimdiye kadar gördüğüm diğer LLM üretimi kodlar gibi amatörce olabileceğinden şüpheleniyorum.
Hatta kodun ne yapmaya çalıştığını anlamama bile yardımcı oldu.
Meta çalışanlarının geliştiricilere yönelik AI’ı tanıtmak için yazdığı 12 sayfalık bir makale olması ilginç; hatta Sankey diyagramı bile kullanmışlar.
Yanılıyor olabilirim ama bu şekilde sunuyorlarsa yeniden üretilebilir bilgi de sağlamaları gerekmez mi diye düşünüyorum.
Komplo teorisi değil; sadece Meta’nın eğitimde kullandığı düzeyde veri bende yok. Acaba bir şeyler yayımladılar mı merak ediyorum.
İleride devasa otomatik üretilmiş test külliyatını bakımını yapmanın maliyetinin ne olacağını merak ediyorum.
Yalnızca test senaryoları üretmekle kalmayıp bunları güncellemenin otomatik bir yolunu da sağlamaları gerekiyor.