Copilot Test Agent ile Test Kapsamı Nasıl Artar?

⏱️ 3 dk okuma📅 15 Eylül 2026

Test yazmanın değerini çoğu ekip zaten biliyor; zor olan, sınırlı zamanı hangi sınıfa ve hangi kod yoluna ayıracağına karar vermek. Visual Studio’nun kod kapsamı analizi ile GitHub Copilot’ın Test Agent yeteneği birlikte kullanıldığında bu karar veriye dayanıyor. Aaron Powell’ın Visual Studio Blog’da paylaştığı örnekte Interview Coach uygulamasının test kapsamı bu yolla %37’den %81’e çıkıyor, hiç testi olmayan üç proje de kapsama giriyor.

Önce bir temel ölçüm (baseline) alın

Yazının üzerinde en çok durduğu nokta, teste başlamadan önce mevcut durumu ölçmek. Yoksa “test yazmış olmak için test yazma” tuzağı çok yakın. Visual Studio’da bunun için Analyze Code Coverage for All Tests komutu kullanılıyor ve komuta iki yoldan ulaşılabiliyor:

Command Palette üzerinden (CTRL + SHIFT + P)
Doğrudan Tests menüsünden

Analiz çalıştırıldığında ortaya çıkan tablo projenin gerçek durumunu döküyor. InterviewCoach.Agent projesinde ciddi boşluklar var, InterviewCoach.Mcp.InterviewData projesinin ise hiç testi yok. Kapsam %37’den başlıyor.

Bu ölçüm sonraki adımların önceliğini de belirliyor. Hiç testi olmayan bir proje, zaten iyi kapsanan bir projeye birkaç test daha eklemekten çok daha yüksek getiri sunuyor. Yazıda ilk hedef olarak InterviewCoach.Mcp.InterviewData projesindeki InterviewSessionTool sınıfı seçiliyor.

Tek bir sınıf için Copilot Test Agent

Hedef sınıf yapısal olarak teste uygun. Bir repository arayüzü alıyor, dolayısıyla veritabanı çağrıları mock’lanabiliyor; metotlar da repository ile çalışmak üzere bir payload alıyor. Bağımlılıkları izole etmeyi kolaylaştırdığı için otomatik test üretimine de elverişli bir tasarım.

Süreci hızlandırmak adına GitHub Copilot’ın Test Agent’ına testlerin yazılacağı dosya veriliyor. Ajan şu sırayla ilerliyor:

Önce sınıfı analiz ediyor.
Ardından çözümün (solution) genelini inceleyerek doğru test yaklaşımını belirliyor.
Proje için henüz bir test sınıfı bulunmadığından yeni bir test projesi oluşturuyor.
Gerekli referansları ekliyor.
Test senaryolarını yazıyor.

Birkaç dakika sonra ajan işini bitirip yaptıklarının özetini sunuyor. 8 yeni test yazmış, bir de yeni test projesi kurmuş. Testler çalıştırılıyor, ardından ajanın önerisiyle kapsam raporu yeniden alınıyor. Başlangıç durumuna göre kayda değer bir iyileşme var.

Ajan, test dosyalarının yanında proje iskeletini ve referansları da kuruyor. Yeni bir test projesini sıfırdan ayağa kaldırmanın manuel maliyeti düşünüldüğünde, zaman kazancının büyük kısmı bu adımdan geliyor.

Çözüm genelinde boşluk analizi: `@test #solution`

Tek sınıf düzeyindeki iyileştirme işe yarıyor ama kod tabanının büyük bölümü hala testsiz. Bu noktada Test Agent’a çözümün tamamını analiz etmesi söyleniyor:

@test #solution

Burada #solution bağlamı kullanıldığı için ajan tek bir dosyaya değil tüm projelere ve kod yollarına bakıyor. Yine birkaç dakikalık bir çalışmanın ardından Copilot şunları kapsayan testlerle dönüyor:

Repository katmanı
DbContext
Extension metotları
InterviewCoach.Agent projesinde ek testler

Ajan, AgentMode.cs gibi yalnızca bir enum içeren dosyalar için test yazmanın değer üretmeyeceğini tespit edip bunları dışarıda bırakıyor. Amaç kapsam yüzdesini yapay biçimde şişirmek olsaydı o dosyalar da listeye girerdi; burada anlamlı kod yolları kapsanıyor.

Bu turun sonunda kapsam %37’den %81’e yükseliyor, başlangıçta hiç testi olmayan üç proje de kapsama alınmış oluyor.

Bu akıştan ne çıkarmalı?

Yazının özü, iki aracın birbirini tamamlaması üzerine kurulu:

Visual Studio kod kapsamı analizi, nereye yatırım yapılacağını gösteren haritayı veriyor. Testin değerini bilmek yeterli değil, eforun nereye harcanacağı çoğu zaman göz ardı edilen kısım.
Test Agent ise bu haritaya göre ya tek bir sınıf için hedefli testler üretiyor ya da çözüm genelinde analiz yapıp toplu iyileştirme getiriyor.

Pratikte sıralama şöyle kuruluyor: önce baseline ölçülür, testsiz veya düşük kapsamlı projeler belirlenir, dar kapsamlı bir sınıfla başlanıp sonuç doğrulanır, sonra @test #solution ile geneli taranır. Her turdan sonra kapsam raporunu yeniden çalıştırmak, ilerlemenin gerçek olup olmadığını görmenin en basit yolu.

Bir de şu var: kaynak yazı, üretilen testlerin kalitesine dair ayrıntılı bir değerlendirme içermiyor, aktarılan veriler kapsam yüzdesi, üretilen test sayısı ve kapsanan bileşenlerle sınırlı. Üretilen testleri kod incelemesinden geçirmek, özellikle mock kurulumlarının gerçek davranışı doğrulayıp doğrulamadığını kontrol etmek yine ekibin sorumluluğunda.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102