Birim Test Üretimi İçin Polyglot Copilot Ajanı
Kod ajanına gönderilen en sık isteklerden biri tek cümleliktir: “Unit test üret.” Bu istek pek çok soruyu havada bırakır: Hangi kod için test yazılacak? Proje hangi test çatısını kullanıyor? Testler nereye konmalı? Derleme onları nasıl bulacak? Neyi doğrulamaları gerekiyor? Microsoft ekibi bu boşluğu doldurmak için code-testing-generator adını verdiği açık kaynaklı, çok dilli bir birim test üretim ajanı yayımladı. Ajan, dotnet/skills deposu içindeki dotnet-test eklentisinin parçası olarak dağıtılıyor.
Bu yazıda ajanın çalışma akışını, karşılaştırmalı ölçüm sonuçlarını ve kurulum adımlarını kaynağa sadık kalarak özetliyorum.
Ajanın kapsamı ve çalışma mantığı
Ajan yalnızca birim testleri üretmeye odaklanıyor: test edilecek kodu izole ediyor, harici servisleri ve dış bağımlılıkları mock’luyor. Entegrasyon, uçtan uca, tarayıcı ve performans testleri şu an için kapsam dışı.
Önemli bir ayrıntı var: Ajan testleri geçirmekle yetinmiyor. Assertion’ları, istenen senaryoların karşılanıp karşılanmadığını ve deponun olağan test komutunun yeni testleri bulup bulmadığını da denetliyor.
Önce depodan öğrenme
Ajan doğrudan test yazmaya başlamıyor. Önce depoyu tarayıp test edilecek kodu, kullanılan dili ve test çatısını tespit ediyor. Var olan testleri inceleyerek yeni testlerin nereye ve nasıl yazılacağını çıkarıyor; doğru derleme ve test çalıştırma komutlarını da buluyor.
Bu adım, sık karşılaşılan bir soruna karşı önlem: Yeni bir test projesi tek başına derlenip geçebilir ama solution’a veya deponun test komutuna eklenmediği için CI’da hiç çalışmayabilir. Ajan, deponun testleri nasıl keşfettiğini kontrol edip yeni testlerin bu akışta göründüğünü doğruluyor.
İş yüküne göre üç farklı yol
Tek bir metot için büyük bir plan gereksizken tüm bir çözüm için gerekli olabiliyor. Ajan üç yaklaşımdan birini seçiyor:
- Direct: İlgili kodu okur, testleri yazar ve sonucu doğrular.
- Single pass: Bir kez araştırıp planlar, ardından bu planı uygular.
- Iterative: Geniş kapsamlı bir istek veya kapsama hedefi için döngüyü tekrarlar.
Plan, yazım ve düzeltme
Büyük görevlerde ajan test edilecek kodun listesini çıkarıyor; basit koddan başlayıp bağımlılığı fazla olana doğru ilerliyor ve her davranışı bir test dosyasına eşliyor. Bir modül için yapılan istek, deponun tüm test projelerini değiştirmemeli ilkesine bağlı kalıyor.
Ajan yerel kuralları izliyor ve testleri iş üzerindeyken çalıştırıyor. Üretilen kod derlenmezse düzeltiyor, hatalı assertion varsa kaynağı yeniden okuyarak testi güncelliyor. Test üretimi sırasında üretim kodunu değiştirmiyor; dış URL çağıran, port açan veya zamanlamaya bağlı testler oluşturmaktan kaçınıyor.
Testlerin değerli olduğunu doğrulama
Bir testin geçmesi, faydalı olduğu anlamına gelmiyor. Yalnızca sonucun null olmadığını kontrol edebilir, yanlış metodu test edebilir ya da metodun her zaman varsayılan değer döndürmesi nedeniyle geçebilir. Ajan bitirmeden önce şunları yapıyor:
- Testleri düşürmesi gereken küçük kod değişikliklerini değerlendiriyor (hafif bir mutasyon testi biçimi).
- Zayıf veya eksik assertion’ları arıyor.
- Talep edilen her senaryonun bir test karşılığı olduğunu kontrol ediyor.
- Çalışma alanının tamamını derliyor ve tüm test paketini çalıştırıyor.
- Deponun test komutunun yeni testleri bulduğunu doğruluyor.
Karşılaştırmalı ölçüm sonuçları
Microsoft ekibi ajanı, 152 görev içeren dahili birim test kıyaslamasında değerlendirdi. Görevler gerçek depolardan alınmış; bir kısmı ayrıntılı, bir kısmı pek çok kararı ajana bırakan “muğlak” istemler. Karşılaştırma dört kurulumda yapıldı: stok GitHub Copilot, stok Claude Code, ajanın GitHub Copilot içindeki hâli ve ajanın Claude Code içindeki hâli. Aşağıdaki sonuçlar aksi belirtilmedikçe GitHub Copilot karşılaştırmasına odaklanıyor; iki kurulum aynı modeli ve istemleri kullandı.
Bir görevin başarılı sayılabilmesi için depo derlenmeli, tüm testler geçmeli, ajan en az bir test eklemeli ve mevcut testleri silmemeliydi.
Genel sonuçlarda ajan 152 görevin 140’ını, stok Copilot ise 120’sini tamamladı: %92,1’e karşı %78,9, yani %63 daha az başarısızlık. En büyük fark muğlak istemlerde ortaya çıktı.
Muğlak istemler workflow’un değerini gösteriyor
| İstem türü | Özel ajan | Stok Copilot |
|---|---|---|
| Muğlak istemler (89 görev) | 79 (%88,8) | 59 (%66,3) |
| Ayrıntılı istemler (63 görev) | 61 (%96,8) | 61 (%96,8) |
Muğlak istemlerde başarısızlık %67 azaldı ve 20 net kazancın tamamı bu kategoriden geldi. Belirli bir kod değişikliğine (diff) yönelik test isteyen 15 görevde ajan hepsini geçerken stok Copilot hiçbirini geçemedi.
Daha fazla test değil, daha güvenilir sonuç
| Metrik | Özel ajan | Stok Copilot |
|---|---|---|
| Tamamlanan görev | 140/152 (%92,1) | 120/152 (%78,9) |
| Derlenen çözüm | 148 | 145 |
| Geçen test paketi | 149 | 147 |
| Üretilen test | 6.963 | 7.129 |
| Ortalama satır kapsamı | %72,4 | %72,2 |
| Ortalama dal kapsamı | %49,8 | %49,1 |
| Ortalama görev süresi | 359 sn | 380 sn |
Özel ajan %2,3 daha az test üretti ve fiili olarak aynı kapsamı sağladı; ortalama olarak yaklaşık %5,5 daha hızlıydı. Kazanç daha fazla test üretmekten değil güvenilirlikten geldi.
Model ve dil çeşitliliği
45.NET görevi üç farklı modelle çalıştırıldı:
| Model | Özel ajan | Stok Copilot | Hata azalması |
|---|---|---|---|
| Claude Opus 4.8 | 43/45 (%95,6) | 35/45 (%77,8) | %80 |
| GPT-5.5 | 41/45 (%91,1) | 36/45 (%80,0) | %56 |
| Claude Haiku 4.5 | 34/45 (%75,6) | 25/45 (%55,6) | %45 |
Workflow her modele katkı sağladı. Tüm 152 görev genelinde özel GPT-5.5 %90,1’e ulaşıp özel Opus’un iki puan yakınına indi ve stok Opus’u 11 puandan fazla geride bıraktı. Bu, güçlü bir workflow’un orta seviye bir modeli en iyi sonuca yaklaştırabildiğine işaret ediyor.
Ajan;.NET, Python, TypeScript, JavaScript, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell ve C++ için rehberlik içeriyor. C# kalıplarını her yere uygulamak yerine her deponun kendi kurallarını öğreniyor. Aynı Opus çalıştırmasında diğer dillerdeki sonuçlar şöyle:
| Dil | Özel ajan | Stok Copilot |
|---|---|---|
| Python (15 görev) | 13 (%86,7) | 6 (%40,0) |
| Go (15 görev) | 15 (%100) | 10 (%66,7) |
| PowerShell (10 görev) | 7 (%70,0) | 8 (%80,0) |
Ajan tüm Go görevlerini geçti ve Python tamamlama oranını iki katından fazla artırdı. PowerShell’de ise stok Copilot bir görev daha fazla tamamladı; örneklem küçük olduğundan bu sonuçlar kesin bir vaat değil, yol gösterici sinyal olarak değerlendiriliyor.
Daha zor bir kıyaslama: SWE Atlas
Workflow bir de SWE Atlas içindeki 44 birim test görevinde denendi. Bu kıyaslama, gereksinimleri kontrol eden ve testlerin hataları yakalayıp yakalayamadığını görmek için kod değişiklikleri uygulayan zorlu bir set.
| Metrik | Özel ajan | Stok Copilot |
|---|---|---|
| Tamamlanan görev | 16/44 (%36,4) | 12/44 (%27,3) |
| Yalnızca bir kurulumun geçtiği görev | 4 | 0 |
| Geçen üretilen test | 550 | 493 |
| Enjekte edilen hataları yakalayan test | 360 | 316 |
Özel ajan dört görevi daha tamamladı ve stok tarafta hiçbir tek başına kazanım olmadı. Yine de tamamlama oranları dahili kıyaslamaya göre çok daha düşük; ekip, SWE Atlas’ta iyileştirilecek çok alan olduğunu belirtiyor.
Öne çıkan çıkarımlar
En net kazanç güvenilirlik alanında oldu: derlenip geçen ve isteğe uyan test üretimi belirgin biçimde arttı, fark özellikle muğlak istemlerde ve kod değişikliğine bağlı görevlerde büyüktü.
Her iki kurulum da geçerli sonuç ürettiğinde hiçbir taraf tüm kalite ölçütlerinde önde değildi. Stok Copilot assertion ve kapsamda az farkla önde çıkarken özel ajan, temiz yapı ve yavaş veya kırılgan kalıplardan kaçınma gibi test hijyeni ölçütlerinde önde. Ancak gruplar farklı görevleri içerdiğinden bu doğrudan bir kalite sıralaması değil; ekibin sonraki iyileştirme yönü daha derin assertion’lar ve hata yolu testleri olarak tanımlanıyor.
Verimlilik tarafında ajan, tamamlanan görev başına yaklaşık %3,2 daha fazla token kullandı. Bu sayılar önbelleklenmiş girdiyi de içerdiğinden doğrudan maliyeti yansıtmıyor.
Sonuçlar yalnızca birim testlerini kapsıyor. Ekip, aynı workflow’un başka test türlerinde nerede yardımcı olabileceğini araştırdığını, ancak duyurulacak taahhütlü bir plan olmadığını belirtiyor.
Kurulum ve kullanım
Ajan, skill dosyaları ve dil rehberleri dotnet/skills deposunda açık kaynak olarak yayımlandı. Eklenti GitHub Copilot CLI’de kullanılabiliyor; hâlâ önizleme aşamasındaki plugin desteği üzerinden Visual Studio Code ve VS Code Insiders’ta da erişilebiliyor. Visual Studio desteği üzerinde çalışıldığı belirtiliyor.
GitHub Copilot CLI’de marketplace’i eklemek ve eklentiyi kurmak için:
/plugin marketplace add dotnet/skills
/plugin install dotnet-test@dotnet-agent-skillsCLI yeniden başlatıldıktan sonra ajanlar listesinden code-testing-generator seçilebiliyor ve klasik “Generate unit tests.” istemiyle deneme yapılabiliyor. Ajanın planı, ürettiği testler ve son doğrulamalarını inceledikten sonra tek bir fonksiyon, tek bir modül veya belirli bir kapsam hedefi için de test isteyebilirsiniz.
Kaynaklar ve İleri Okuma
- From generated code to trusted code with a unit-test agent —.NET Blog (Amaury Levé)
- dotnet-test eklentisi — dotnet/skills
- code-testing-generator ajan tanımı
- dotnet/skills deposu
- SWE-Atlas kıyaslama deposu
- Visual Studio Agent Skills: Copilot’a Takımınızı Öğretmek
- Visual Studio’da Yerleşik Agent Skills:.NET ve Azure
- Visual Studio’da Plan Agent: Kodu Yazmadan Önce Durup Düşünmek
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder