# Yapay zeka ile test yazmak: kodlama ajanları rehberi

Adres: https://agentvera.dev/blog/yapay-zeka-ile-test-yazmak/ · Yayın: 2026-10-25

Yapay zeka ile test yazmak için pratik rehber: gerçekten hata yakalayan birim testleri, karakterizasyon testleri, kapsam boşlukları, mutasyon testi ve iki ajanlı düzen.

**Kısaca:**

- Ajan testi hızlı yazar, ama okuduğu kodu aynen tekrar eden bir test hiçbir şey kanıtlamaz; beklenen değeri koddan değil, kurallardan iste.
- Test edilmeyen kodu bulmak için kapsamı, zayıf testleri bulmak için mutasyon testini kullan: ters çevrilmiş bir koşul hayatta kalıyorsa testler seni korumuyordur.
- İşi bölmek iyi sonuç verir: bir ajan testleri yazar, diğeri kodu; kodu yazan ajan testleri geçsin diye testleri değiştiremez.
- AgentVera’da dosya sahipliği uygulayıcı ajanı test klasöründen uzak tutar, Verify sonucu kriterlerine göre kontrol eder, Turlar da kötü bir turu geri alır.

Yapay zeka ile test yazmanın kolay kısmı test elde etmektir. Herhangi bir kodlama ajanından “bu modül için test yaz” dersen birkaç dakikada kırk yeşil testin olur. Zor kısım, kod yanlış olduğunda kırmızıya dönen testler elde etmektir. Bir fonksiyonu okuyup sonra o fonksiyonun ne döndürdüğünü doğrulayan bir ajan, çoğu zaman fonksiyonu ikinci kez yazmış olur.

Bu rehberde Claude Code, Codex ya da Gemini CLI gibi ajanlardan işe yarar test almanın yolunu anlatıyorum: ne istemelisin, hiçbir şey kanıtlamayan testleri nasıl fark edersin, testleri kapsam ve mutasyon testiyle nasıl ölçersin ve kodu yazan ajanın testleri sessizce eğip bükmemesi için işi nasıl bölersin.

## Yapay zekanın yazdığı testler neden ters gider?

Ajanlar testin mekanik kısmında çok iyidir: fixture’lar, factory’ler, mock’lar, parametreli durumlar, yeni bir test dosyasının iskeleti. Kaydıkları yer, testi değerli kılan şeydir: beklenen değer.

Ajan test yazarken genellikle uygulama kodu bağlamında açıktır. En doğal hareket kodu okumak, ne döndürdüğünü bulmak ve tam olarak onu doğrulamaktır. Kodda bir hata varsa test artık o hatayı kilitler. Yeşildir, satırları kapsar ve hatayı hiç düzeltmesen de yeşil kalır.

Bunun birkaç yaygın biçimi var:

- **Aynalanmış mantık.** Test beklenen değeri kodla aynı formülle hesaplar: `expect(price(100, 0.2)).toBe(100 - 100 * 0.2)`. Formül yanlışsa ikisi birlikte yanlıştır.
- **Test edilen şeyi mock’lamak.** Test edilen birim mock’lanır, test de mock’u kontrol eder.
- **Yalnızca çağrı kontrolü.** `expect(sendEmail).toHaveBeenCalled()`; ne gönderildiğine ya da kime gönderildiğine bakılmaz.
- **Her şeye snapshot.** Kimsenin okumadığı devasa bir snapshot, her kırıldığında `-u` ile güncellenir.
- **Başarısız olamayan doğrulamalar.** Her zaman nesne döndüren bir fonksiyonda `expect(result).toBeDefined()`.
- **Testi geçsin diye değiştirmek.** Kod bir testten kalır, ajan da kodu değil testin beklenen değerini “düzeltir”.

Bunların hiçbiri yapay zekaya özgü değil, insanlar da yazar. Ajanlar bunları daha hızlı ve daha büyük partiler halinde üretir; bu yüzden onları yakalayan bir sürece ihtiyacın var.

## Koddan değil, davranıştan başla

En büyük iyileşme, ajana kodun ne yapması gerektiğini söylemek ve beklenen değerleri uygulamanın eline bırakmamaktır.

Zayıf bir istem:

> `src/billing/discount.ts` için birim testleri yaz.

Daha iyisi:

> `src/billing/discount.ts` içindeki `applyDiscount` için birim testleri yaz. Kurallar: yüzde indirim toplamı asla sıfırın altına düşürmez; indirimler üst üste binmez, en büyüğü geçerli olur; süresi dolmuş kod hata vermez, yok sayılır; tutarlar 2 ondalığa, yarım yukarı yuvarlanır. Beklenen değerleri bu kurallardan elle hesapla, uygulamayı okuyarak ya da çalıştırarak değil. Bir kural mevcut kodla çelişiyor gibi görünürse testi yine de yaz ve hangi testlerin kaldığını bana söyle.

Üç şey değişti. Kurallar senden geliyor; ya da bir iş kaydından, şartnameden, dokümandan. Beklenen değerler kurallardan çıkarılmış sabitler. Ve başarısız test serbest: gerçek bir hata olabilir, ki testler tam da bunun için var.

Birkaç alışkanlık daha işe yarar:

- **Önce durum listesini iste.** “Kod yazmadan önce test etmeyi planladığın durumları birer satırla listele.” Ajanın atladığı uç durumları (boş girdi, unicode, saat dilimleri, tam sıfırdaki sınır) daha hiç kod yokken ekleyebilirsin.
- **Sınırları adlandır.** Boyutu gösterirsen ajanlar uç durumlarda iyidir: “her sınırın tam üstünde, hemen altında ve hemen üstündeki girdiler”.
- **Neyin mock’lanmayacağını söyle.** “`src/billing` içinde hiçbir şeyi mock’lama; yalnızca HTTP istemcisini mock’la.” Totolojik testlerin çoğu aşırı mock’lamayla başlar.
- **Her testte bir davranış.** `ignores_expired_codes` gibi net adlı testleri incelemek, on iki doğrulamalı tek bir testi incelemekten kolaydır.

## Birim, entegrasyon ve uçtan uca testler

Aynı ajan üçünü de yazabilir, ama talimatlar farklıdır.

### Birim testleri

Hızlı, yalıtılmış ve çok sayıda. Ajanların en çok zaman kazandırdığı yer burası. Ajanı mevcut test stiline yönlendir (“`tests/billing/tax.test.ts` dosyasındaki stili izle”), yoksa her seferinde yeni bir yardımcı kütüphane alırsın. Test komutunu `CLAUDE.md` ya da `AGENTS.md` dosyana yaz ki ajan testleri kendisi çalıştırsın; ayrıntısı [CLAUDE.md nasıl yazılır](/blog/claude-md-nasil-yazilir/) yazısında.

### Entegrasyon testleri

Bunlar gerçek bir veritabanına, kuyruğa ya da dosya sistemine dokunur. Ajanlar burada mock’a uzanma eğilimindedir ve entegrasyon testi yeniden birim testine döner. Açık ol: “`docker-compose.test.yml` içindeki test veritabanını kullan; repository katmanını mock’lama.” Temizliği de iste ki testler birbirinin artığına bağımlı kalmasın.

### Uçtan uca testler

Tarayıcı testlerinde ajan, anlattığın kullanıcı akışından Playwright ya da Cypress testleri yazabilir. Zayıf nokta seçicilerdir: bir sonraki tasarım değişikliğinde kırılan CSS yolları yerine rol ya da etiket tabanlı seçiciler iste (`getByRole('button', { name: 'Öde' })`). Ajanın kendi işini gerçek bir tarayıcıda kontrol etmesini [yapay zeka ajanı ile tarayıcı testi](/blog/yapay-zeka-ajani-tarayici-testi/) yazısında anlattım.

## Henüz anlamadığın kod için karakterizasyon testleri

Bazen ortada şartname yoktur. Kod eskidir, yazan gitmiştir ve tam olarak ne yaptığını kimse bilmez. Burada hedef tersine döner: kodun bugün ne yaptığını, hataları dahil, kaydeden testler istersin; böylece bu değiştiğinde fark edersin.

Bunlara karakterizasyon testi denir ve ajanın uygulamayı okumasına izin vermenin doğru olduğu yerlerden biridir. İstem de buna göre değişir:

> `legacy/invoice_export.py` için karakterizasyon testleri yaz. Hata gibi görünenler dahil mevcut davranışı kaydet; hiçbir şeyi düzeltme. Bulabildiğin her dalı kapsa. Yanlış görünen her davranışı nedenini açıklayan bir `# SUSPICIOUS:` yorumuyla işaretle.

`SUSPICIOUS` notları sonraki hata listen olur. Okunacak kadar küçük oldukları sürece snapshot ya da onay (approval) tarzı testler burada uygundur. Bu, güvenli her refactor’ün ilk adımıdır; [yapay zeka ile eski kodu refactor etmek](/blog/yapay-zeka-ile-eski-kodu-refactor-etmek/) rehberi bu yolu adım adım anlatıyor.

## Kapsamı boşluk bulmak için kullan, not vermek için değil

Kapsam iyi bir harita, kötü bir karnedir. Ajana nereye bakacağını göstermek için kullan:

| Yığın | Komut |
| --- | --- |
| Vitest | `npx vitest run --coverage` |
| Jest | `npx jest --coverage` |
| pytest (pytest-cov ile) | `pytest --cov=myapp --cov-report=term-missing` |
| Go | `go test -coverprofile=cover.out ./...` ardından `go tool cover -func=cover.out` |

Vitest için `@vitest/coverage-v8` gibi bir kapsam sağlayıcısının kurulu olması gerekir. pytest’teki `term-missing` raporu kapsanmayan satır numaralarını tek tek listeler; doğrudan isteme yapıştırmak için kullanışlıdır.

İyi bir döngü:

1. Kapsamı çalıştır ve önemli modülleri seç: faturalama, kimlik doğrulama, veri taşımaları; üretilmiş kod değil.
2. Kapsanmayan satırları ajana ver ve hangi davranışı temsil ettiklerini sor.
3. O davranış için, beklenen değerleri kurallardan gelen testler yazdır.
4. Satırların artık çalıştığını görmek için kapsamı yeniden çalıştır.

Yapmaman gereken şey “kapsamı %90’a çıkar” demektir. Bir sayı verilen ajan o sayıya ulaşır ve bunun en ucuz yolu, satırları çalıştırıp pek bir şey kontrol etmeyen testlerdir.

## Mutasyon testi: testler gerçekten bir şey kontrol ediyor mu?

Mutasyon testi, kapsamın cevaplayamadığı soruyu cevaplar. Bir araç kodunda küçük değişiklikler yapar; `>` işaretini `>=` yapar, `+` yerine `-` koyar ya da boş değer döndürür; ve testlerini her değişikliğe karşı çalıştırır. Testler yine geçerse mutant “hayatta kalmıştır” ve testlerin davranışı gerçekten kontrol etmediği bir yer bulmuşsundur.

Yaygın araçlar:

- **JavaScript ve TypeScript:** StrykerJS. `npm init stryker@latest` ile kur, `npx stryker run` ile çalıştır.
- **Python:** mutmut. `mutmut run` ile çalıştır, hayatta kalan mutantları `mutmut browse` ile gez. Yeni sürümler fork desteği istediği için Windows’ta WSL altında çalışır.
- **Java:** PIT, örneğin `mvn test-compile org.pitest:pitest-maven:mutationCoverage`.
- **Rust:** cargo-mutants; `cargo install cargo-mutants` ile kurulur, `cargo mutants` ile çalışır.

Büyük bir kod tabanında mutasyon çalıştırmaları yavaştır; üzerinde çalıştığın modülle sınırla. Sonra hayatta kalanları ajana ver:

> `discount.ts` içinde şu mutantlar hayatta kaldı: (liste). Her biri için, mutantta kalan ve orijinalde geçen bir test yaz. `discount.ts` dosyasını değiştirme.

Bu, ajanın testteki en iyi kullanımlarından biridir. Görev net, başarı kontrolü mekanik, sonuç da gerçek bir hata türünü yakaladığı kanıtlanmış bir testtir.

## Bir ajan testi, diğeri kodu yazsın

Ajanın testleri eğip bükmesini durdurmanın en güvenilir yolu, kodu yazan ajanın testlere dokunamamasıdır.

Düzen basit:

1. **Test ajanı.** Şartnameyi alır ve testleri `tests/` klasörüne (ya da testlerin nerede duruyorsa oraya) yazar. Uygulamayı görmez, yazmaz. Özellik henüz olmadığı için testleri başta kırmızıdır.
2. **Uygulayıcı ajan.** Aynı şartnameyi ve kırmızı testleri alır, testler geçene kadar kodu yazar. `tests/` içindeki hiçbir şeyi düzenleyemez.
3. **Anlaşmazlık geri gider.** Uygulayıcı bir testin yanlış olduğunu düşünürse testi düzenlemek yerine test ajanına ya da sana sorar.

Bu, iki ajana bölünmüş test güdümlü geliştirmedir (TDD) ve farklı sağlayıcılar arasında da çalışır. Bazı ekipler testleri bir modelin, uygulamayı başka bir modelin yazmasını tercih eder; böylece ikisi aynı kör noktaları paylaşmaz.

Aynı özellikte iki ajan çalıştırmak, birbirlerinin ayağına basmamaları için biraz yalıtım ister. Her ajana ayrı bir [git worktree](/sozluk/git-worktree/) vermek olağan çözümdür; bkz. [git worktree ile paralel geliştirme](/blog/git-worktree-paralel-gelistirme/). Bu bölünmede farklı klasörlere yazdıkları için ikisini aynı worktree’de de tutabilirsin.

## Yapay zekanın yazdığı testleri incelemek

Testleri en az kod kadar dikkatli oku. Kısa bir kontrol listesi:

- **Beklenen değerler kurallardan mı geliyor?** Koddan kopyalanmış formüllere değil, sabitlere bak.
- **Kod yanlış olsaydı bu test kalır mıydı?** Bir test seç ve kodu elle boz. Yeşil kalıyorsa test süsten ibarettir.
- **Önemli bir şey mock’lanmış mı?** Sınırdaki mock’lar sorun değil; test edilen kodun mock’u sorundur.
- **Mevcut bir test değişti mi?** Bir özellik dalında eski testlerin beklenen değerlerinin değişmesi soru sormayı hak eder. `git diff --stat -- tests/` bunu bir bakışta gösterir.
- **Adlar okunaklı mı?** Kırmızı bir testin adı neyin kırıldığını söylemeli.
- **Kararsız (flaky) mı?** Gerçek zamana, rastgele veriye, ağ çağrılarına ve test sırasına dikkat et. Ajandan yeni testleri birkaç kez çalıştırmasını iste.

Otomatik kod incelemesi burada da işe yarar. Diff’i okuyan ikinci bir model, hiçbir şey doğrulamayan bir testi çoğu zaman fark eder. Nasıl çalıştığını [yapay zeka ile kod incelemesi](/blog/yapay-zeka-kod-incelemesi/) yazısında anlattım.

## Sık yapılan hatalar

- **Başka hiçbir şey demeden “bu dosya için test yaz”.** Uygulamayı, bir kez daha anlatılmış haliyle alırsın.
- **Bir kapsam sayısının peşine düşmek.** Kontrol edilen davranış değil, çalıştırılan satır alırsın.
- **Uygulayıcının testleri düzenlemesine izin vermek.** Yeşile giden en hızlı yol değiştirilmiş bir doğrulamadır.
- **Snapshot’ları okumadan güncellemek.** `-u`, bir gerilemeyi yeni beklenen çıktıya çevirir.
- **Silmek üzere olduğun koda test yazmak.** Tutacağın davranışı test et.
- **Kararsız testleri bırakmak.** Kararsız bir testin kaldığını gören ajan, bozuk olmayan bir şeyi seve seve “düzeltir”. Aynısı [CI hatasını yapay zekaya düzelttirirken](/blog/ci-hatasini-yapay-zeka-duzeltsin/) de geçerli.

## AgentVera’da nasıl yapılır?

AgentVera kodlama ajanı CLI’larını proje başına yan yana çalıştırır; test ajanı ve uygulayıcı düzenini kurmak birkaç dakika sürer.

- **İki ajan, tek özellik.** Aynı projede bir test ajanı ve bir uygulayıcı aç; aynı CLI’da ya da farklılarında, örneğin testler için Claude Code, kod için Codex. İşi ana klasörünün dışında tutmak istersen worktree panelinden ayrı bir worktree’ye koy.
- **Dosya sahipliği uygulayıcıyı testlerden uzak tutar.** Test ajanının diyaloğunda “Sahip olduğu alanlar” alanına `tests/**` yaz. O çalıştığı sürece diğer ajanlar bu dosyaları düzenleyemez. Claude Code ajanlarında düzenleme bir PreToolUse hook’uyla daha yapılmadan reddedilir; Codex ve diğer CLI’lar kuralı talimatlarında alır. Reddedilen denemeler ekip zaman çizelgesinde görünür.
- **Anlaşmazlıklar için ajanlar arası mesajlaşma.** Uygulayıcı bir testin yanlış olduğunu düşündüğünde testi düzenlemek yerine test ajanına doğrudan yazıp cevabını bekleyebilir.
- **Verify sonucu kontrol eder.** “Bitti”nin ne demek olduğunu mesajına yaz; örneğin “`tests/billing` içindeki tüm testler geçiyor ve hiçbir test dosyası değişmedi”. Verify bunu kriterlere çevirir; ajanın turu bittiğinde ayrı bir doğrulayıcı testleri çalıştırır ve her kriteri kanıtıyla işaretler. Doğrulayıcı depoyu okuyup test komutlarını çalıştırabilir, ama dosya düzenleyemez.
- **Kod incelemesi testleri de okur.** Otomatik kod incelemesi her turun değişikliklerini seçtiğin Claude modeliyle inceler ve bulguları önem derecesi ve dosya:satır ile listeler; zayıf doğrulamalara ikinci bir göz.
- **Kötü bir turu geri al.** Her turun başında klasörün anlık görüntüsü alınır; ajan test takımının yarısını istemediğin bir yöne çekerse panel başlığındaki **Turlar**’dan o turu geri alıp yeniden denersin. Bkz. [Claude Code değişikliklerini geri alma](/blog/claude-code-degisiklikleri-geri-alma/).

## Sonuç

Yapay zeka test yazmayı ucuzlatır; bu da işi test yazmaktan testleri değerlendirmeye kaydırır. Ajana kod yerine davranış ver, beklenen değerleri uygulamanın erişiminden uzak tut, kapsamı harita, mutasyon testini karne olarak kullan ve kodu yazan ajanın “geçmek” ne demek ona da karar vermesine izin verme. Bunu yaptığında hız gerçek olur: hızla büyüyen ve bir şey kırıldığında hâlâ kırmızıya dönen bir test takımı.

Daha fazlası için:

- [Verify](/ozellikler/verify/)
- [Dosya sahipliği](/ozellikler/dosya-sahipligi/)
- [Ajanlar arası mesajlaşma](/ozellikler/ajanlar-arasi-mesajlasma/)
- [Kod incelemesi](/ozellikler/kod-incelemesi/)
- [Turlar ve oturum tekrarı](/ozellikler/turlar-ve-oturum-tekrari/)
- [Paralel kodlama ajanları](/blog/paralel-kodlama-ajanlari/)

AgentVera’yı denemek için [ana sayfaya](/) göz at.

## Sık sorulanlar

**Yapay zeka iyi birim testi yazabilir mi?** Yönlendirirsen evet. Ajanlar kurulum, fixture, uç durum listesi ve kalıp kodda iyidir. Beklenen değeri test ettiği koddan çıkardıklarında zayıflarlar, çünkü o zaman test yalnızca uygulamayı tekrar eder. Onlara beklenen davranışı ver, testleri de mutasyon testiyle kontrol et.

**Totolojik test nedir?** Kuruluşu gereği geçen testtir: beklenen değeri kodla aynı yöntemle hesaplar, kontrol etmesi gereken şeyi mock’lar ya da yalnızca bir fonksiyonun çağrıldığını doğrular. Mantık yanlış olsa bile yeşil kalır.

**Yapay zekanın yazdığı testlerde %100 kapsam iyi bir hedef mi?** Hayır. Kapsam hangi satırların çalıştığını söyler, bir şeyin kontrol edilip edilmediğini söylemez. Test edilmeyen yerleri bulmak için kullan, testleri ise mutasyon testi ya da dikkatli bir incelemeyle değerlendir.

**Testleri ve kodu aynı ajan mı yazmalı?** Küçük değişikliklerde sorun değil. Önemli mantıkta bölmek işe yarar: bir ajan şartnameden test yazar, diğeri uygular ve uygulayıcı testleri değiştiremez. Böylece en kolay hile, testi geçene kadar düzenlemek, ortadan kalkar.

**AgentVera’da bunun için hangi ajanları kullanabilirim?** AgentVera’nın çalıştırdığı her CLI ajanını: Claude Code, Codex, Gemini CLI ve diğerleri. Dosya sahipliği düzenlemeyi Claude Code ajanlarında baştan engeller; Codex ve diğer CLI’lar sahiplik kurallarını talimatlarında alır.

---

**AgentVera hakkında.** AgentVera, Solviera Teknoloji tarafından geliştirilen macOS, Windows ve Linux masaüstü uygulamasıdır. 18 yapay zeka kodlama ajanını (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) proje bazında, gerçek terminallerde ve kullanıcının kendi CLI kurulum ve girişleriyle yan yana çalıştırır. Ücretsiz planda sınırsız ajan vardır. İndir: https://agentvera.dev/indir/ · Fiyatlar: https://agentvera.dev/fiyatlar/