Sınır durumu testleri için Claude Code test oluşturma istemi

Neden sadece "mutlu yol" testleri zaman kaybıdır

Otomatik oluşturulmuş test paketleri genellikle etkileyici görünür: onlarca test, çokça kurulum kodu ve her fonksiyon ismi bir yerde görünür. Ancak bu testlerin çoğu sadece “her şey normalken çalışıyor” kontrolleridir. Kolayca geçerler, nadiren hata yakalarlar ve okunup bakım yapılmaları yine de zaman alır.

Tipik bir Claude Code test oluşturma isteminde model gördüğü örnek girdileri yansıtma eğilimindedir. Farklı görünen ama aynı davranışı kapsayan varyasyonlar elde edersiniz. Sonuç, önemli yerde ince kapsama sahip ama büyük bir test paketi olur.

Yüksek-sinyalli testler farklıdır. Geçmiş ayın olayını yakalayacak küçük test kümesidir. Davranış riskli bir şekilde değiştiğinde başarısız olurlar ve zararsız refaktörlerde stabil kalırlar. Bir yüksek-sinyalli test, yirmi "beklenen değeri döndürür" kontrolüne bedel olabilir.

Düşük-değerli mutlu-yol üretiminin birkaç belirgin belirtisi vardır:

• Birçok test sadece giriş etiketlerinde farklıdır, kırılabilecek şeylerde değil.
• Doğrulamalar yüzeysel olur ("null değil", "durum 200") yerine anlamı kontrol etmek.
• Kurulum, test edilen davranıştan daha ağırdır, bu yüzden insanlar testleri güncellemeyi bırakır.
• Kapsama yüksek görünür, fakat kenar durumlar el değmemiştir.

Bir indirim kodu uygulayan bir fonksiyon hayal edin. Mutlu-yol testleri "SAVE10" fiyatı düşürüyor mu onaylar. Gerçek hatalar başka yerlerde gizlidir: 0 veya negatif fiyatlar, süresi geçmiş kodlar, yuvarlama kenarları veya maksimum indirim sınırları. Bu durumlar yanlış toplamlar, kızgın müşteriler ve gece yarısı geri dönüşlerine sebep olur.

Hedef, “daha çok test”ten “daha iyi test”e geçmektir; üç hedefe odaklanarak: sınırlar, hata modları ve invariantlar.

Üç hedef: sınırlar, hata modları, invariantlar

Yüksek-sinyalli birim testleri istiyorsanız, “daha çok test” istemeyi bırakın ve üç belirli tür isteyin. Bu, faydalı kapsama üreten Claude Code test oluşturma isteminin özüdür; sadece "normal girdiyle çalışır" kontrolleri yığını değil.

1) Sınırlar (hataların saklandığı yerler)

Sınırlar kodun kabul ettiği veya ürettiği şeylerin kenarıdır. Birçok gerçek hata bir eksi-bir, boş durum veya zaman aşımı sorunu olup mutlu yolda ortaya çıkmaz.

Minimum ve maksimum (0, 1, max uzunluk), boş vs var ("", [], nil), eksi-bir hataları (n-1, n, n+1) ve zaman limitleri (kesme noktasına yakın) açısından düşünün.

Örnek: bir API "en fazla 100 öğe" kabul ediyorsa, sadece 3 değil 100 ve 101 test edin.

2) Hata modları (güvenli biçimde başarısız olduğunu kanıtlayın)

Hata modları sistemin kırılma yollarıdır: kötü girdiler, eksik bağımlılıklar, kısmi sonuçlar veya üst akış hataları. İyi hata modu testleri ideal koşullar altındaki çıktıyı değil, stres altındaki davranışı kontrol eder.

Örnek: bir veritabanı çağrısı başarısız olduğunda, fonksiyon açık bir hata döndürüyor mu ve kısmi veri yazmaktan kaçınıyor mu?

3) Invariantlar (her zaman doğru olması gereken kurallar)

Invariantlar bir çağrıdan önce ve sonra her zaman doğru kalması gereken gerçeklerdir. Bu, belirsiz doğruluğu keskin doğrulamalara dönüştürür.

Örnekler:

• Her çekimden sonra "Bakiye asla negatif olmaz".
• Hızlı yaratımlarda "ID'ler benzersizdir".
• "Hata durumunda durum değişikliği olmaz" (yeni satır yok, bayraklar değiştirilmez).

Bu üç hedefe odaklandığınızda, daha az testiniz olur ama her biri daha fazla sinyal taşır.

Hazırlık: test yazmadan önce küçük bir sözleşme çıkarın

Çok erken test istendiğinde genellikle nazikçe "beklendiği gibi çalışıyor" kontrolleri yığını alırsınız. Basit bir düzeltme, önce küçük bir sözleşme yazmak, sonra testleri o sözleşmeden üretmektir. Bu, Claude Code test oluşturma istemini gerçek hataları bulan bir şeye dönüştürmenin en hızlı yoludur.

Yararlı bir sözleşme bir nefeste okunabilecek kadar kısa olmalıdır. Giriş, çıkış ve başka nelerin değiştiği olmak üzere üç soruya cevap veren 5–10 satır hedefleyin.

5–10 satırlık bir sözleşme şablonu

Sözleşmeyi düz dilde, kod değil şekilde yazın ve yalnızca test edebileceğiniz şeyleri dahil edin.

• Girdiler: tipler, izin verilen aralıklar ve neyin "boş" veya "eksik" sayıldığı.
• Çıktı: dönüş değeri veya hata yapısı ve "başarı"nın neyi garanti ettiği.
• Yan etkiler: durum değişiklikleri, veritabanı satırları, ağ çağrıları, dosyalar, loglar.
• Varsayımlar: çağıranların sıklıkla yanlış yaptığı şeyler (zaman dilimi, kodlama, kimlik doğrulama, sıralama).
• "Asla olmamalı": çökme, sessiz veri kaybı, çift ücretlendirme, kısmi yazılar.

Bunu elde ettikten sonra, gerçekliğin varsayımlarınızı nerede bozabileceğine bakın. Bunlar sınır durumları (min/max, sıfır, taşma, boş dizeler, kopyalar) ve hata modları (zaman aşımı, izin reddi, benzersiz kısıt ihlali, bozuk girdi) olur.

İşlev gibi bir özellik için somut bir örnek: reserveInventory(itemId, qty).

Sözleşme qty'nin pozitif tam sayı olması, fonksiyonun atomik olması ve negatif stok yaratmaması gerektiğini söyleyebilir. Bu hemen yüksek-sinyalli testleri akla getirir: qty = 0, qty = 1, mevcut olandan fazla qty, eşzamanlı çağrılar ve yarıda zorlanan bir veritabanı hatası.

Eğer Koder.ai gibi bir sohbet tabanlı araç kullanıyorsanız, aynı iş akışı geçerlidir: önce sohbet içinde sözleşmeyi yazın, sonra sınırlar, hata modları ve "asla olmamalı" listesini doğrudan hedef alan testleri üretin.

İstem kalıbı: yüksek-sinyalli test planı

Daha az test ama her biri işe yarayan testler istediğinizde bu Claude Code test oluşturma istemini kullanın. Ana hareket, önce bir test planı zorlamaktır; sonra planı onayladıktan sonra test kodunu üretmektir.

You are helping me write HIGH-SIGNAL unit tests.

Context
- Language/framework: \u003cfill in\u003e
- Function/module under test: \u003cname + short description\u003e
- Inputs: \u003ctypes, ranges, constraints\u003e
- Outputs: \u003ctypes + meaning\u003e
- Side effects/external calls: \u003cdb, network, clock, randomness\u003e

Contract (keep it small)
1) Preconditions: \u003cwhat must be true\u003e
2) Postconditions: \u003cwhat must be true after\u003e
3) Error behavior: \u003chow failures are surfaced\u003e

Task
PHASE 1 (plan only, no code):
A) Propose 6-10 tests max. Do not include “happy path” unless it protects an invariant.
B) For each test, state: intent, setup, input, expected result, and WHY it is high-signal.
C) Invariants: list 3-5 invariants and how each will be asserted.
D) Boundary matrix: propose a small matrix of boundary values (min/max/empty/null/off-by-one/too-long/invalid enum).
E) Failure modes: list negative tests that prove safe behavior (no crash, no partial write, clear error).
Stop after PHASE 1 and ask for approval.

PHASE 2 (after approval):
Generate the actual test code with clear names and minimal mocks.

Pratik bir numara, sınır matrisini kompakt bir tablo olarak zorlamaktır, böylece boşluklar belirgin olur:

Eğer Claude 20 test önerirse, geri ittirin. Benzer vakaları birleştirmesini ve sadece gerçek bir hatayı yakalayacak olanları tutmasını isteyin.

Adım adım: istemi çalıştırmak ve çıktıyı testlere dönüştürmek

İstediğiniz davranış için küçük, somut bir sözleşmeyle başlayın. Fonksiyon imzasını, girdiler ve çıktılar hakkındaki kısa açıklamayı ve mevcut testleri (yalnızca mutlu-yol olsalar bile) yapıştırın. Bu modeli kodun gerçekte ne yaptığına sabitler, tahminlerine değil.

Sonra herhangi bir test kodu istemeden önce bir risk tablosu isteyin. Üç sütun zorlayın: sınır durumları (geçerli girdinin kenarları), hata modları (kötü giriş, eksik veri, zaman aşımı) ve invariantlar (her zaman doğru olması gereken şeyler). Her satır için bir cümle ekleyin: “neden bu bozulabilir.” Basit bir tablo, bir yığın test dosyasından daha hızlı boşlukları gösterir.

Sonra her birinin benzersiz bir hata yakalama amacı olan en küçük test kümesini seçin. İki test aynı nedenle başarısız oluyorsa, daha güçlü olanı tutun.

Pratik bir seçim kuralı:

• Farklı sınırları vuran testleri tutun (min, max, boş, eksi-bir).
• Başarısızlık altında güvenli davranışı kanıtlayan testleri tutun (açık hata, kısmi yazı yok, çökme yok).
• Bir invariantı doğrulayan testleri tutun (sıralama, toplamlar, idempotentlik, kopya yok).
• Sadece normal girdiyle çalışan testleri kesin.

Son olarak, her test için kısa bir açıklama isteyin: başarısız olursa hangi hatayı yakalardı. Eğer açıklama belirsizse ("davranışı doğrular"), test muhtemelen düşük-sinyallidir.

Invariantları nasıl assert haline getirirsiniz

Bir invariant, geçerli herhangi bir girdiyle bile doğru kalması gereken bir kuraldır. Invariant tabanlı testte önce kuralı düz dilde yazarsınız, sonra onu yüksek sesle başarısız olabilecek bir assert'e dönüştürürsünüz.

Sizi koruyan 1 veya 2 invariant seçin. İyi invariantlar genellikle güvenlik (veri kaybı yok), tutarlılık (aynı girdiler, aynı çıktılar) veya sınırlar (asla kapakları aşma) ile ilgilidir.

Invariantı kanıtlanabilir bir kontrole dönüştürme

Invariantı kısa bir cümle olarak yazın, sonra testin gözlemleyebileceği kanıtı belirleyin: dönüş değerleri, saklanan veriler, yayılan olaylar veya bağımlılıklara yapılan çağrılar. Güçlü assertler hem sonucu hem de yan etkileri kontrol eder, çünkü birçok hata "OK döndü ama yanlış yazdı" şeklinde gizlenir.

Örneğin, bir kupon uygulayan bir fonksiyonunuz varsa:

• Invariant: nihai toplam asla negatif olmaz.
• Invariant: aynı kupon iki kez uygulanmaz.

Şimdi bunları şu şekilde assert'lere dönüştürün:

expect(result.total).toBeGreaterThanOrEqual(0)
expect(db.getOrder(orderId).discountCents).toBe(originalDiscountCents)

"Beklenen sonucu döndürür" gibi belirsiz assertlerden kaçının. Spesifik kuralı (negatif değil) ve spesifik yan etkiyi (indirim bir kez saklandı) assert edin.

Testi keskin tutmak için bir karşıörnek notu ekleyin

Her invariant için testin içinde hangi verinin onu ihlal edeceğine dair kısa bir not ekleyin. Bu, testin zaman içinde mutlu-yol kontrolüne dönüşmesini engeller.

Basit bir kalıp uzun vadede işe yarar:

• Test adında invariantı koyun.
• Çıktıda invariantı assert edin.
• Ana yan etkiyi (veya yan etki olmadığını) assert edin.
• Bir ihlal örneği açıklayan bir yorum ekleyin (örneğin, çok büyük bir kupon değeri veya tekrar uygulama).

Hata modları: güvenli davranışı kanıtlayan testler yazın

Yüksek-sinyalli testler genellikle kodunuzun güvenli şekilde başarısız olduğunu doğrulayan testlerdir. Bir model sadece mutlu-yol testleri yazıyorsa, özellik karmaşık girdiler ve bağımlılıklar karıştığında nasıl davrandığı hakkında neredeyse hiçbir şey öğretmez.

Önce bu özellik için "güvenli"nin ne anlama geldiğine karar verin. Tipik olarak:

• Tipli bir hata döndürür mü?
• Bir varsayılan değere mi geri döner?
• Bir kere yeniden dener mi sonra durur mu?

O beklenen davranışı bir cümleyle yazın, sonra testler bunu kanıtlasın.

Claude Code'dan hata modu testleri istediğinizde, hedefi sıkı tutun: sistemin kırılma yollarını kapsayın ve istediğiniz kesin yanıtı assert edin. Yararlı bir ifade: "Çok sayıda sığ assert yerine daha az test tercih edin, ama güçlü assert'leri olsun."

En iyi testleri üreten hata kategorileri:

• Kötü girdiler: geçersiz formatlar, gerekli alanların eksikliği, aralık dışı değerler
• Bağımlılık hataları: zaman aşımı, 500'ler, boş yanıtlar, bozuk yükler
• Sıralama sorunları: sıra dışı olaylar, kopyalar, kısmi yazılar
• Eşzamanlılık: yarışan güncellemeler, idempotentlik kontrolü
• Kurtarma davranışı: hata döndürme vs geri dönüş vs yeniden deneme

Örnek: kullanıcı oluşturan bir endpoint'iniz olsun ve hoş geldin e-postası göndermek için bir e-posta servisini çağırsın. Düşük-değerli bir test "201 döner" der. Yüksek-sinyalli bir hata testi, e-posta servisi zaman aşımına uğrarsa ya (a) yine de kullanıcı oluşturulur ve 201 ile "email_pending" bayrağı döndürülür, ya da (b) 503 döndürülür ve kullanıcı oluşturulmaz. Bir davranış seçin, sonra hem yan etkiyi hem yanıtı assert edin.

Ayrıca ne sızdırmadığınızı test edin. Doğrulama başarısızsa, veritabanına hiçbir şey yazılmadığını doğrulayın. Bir bağımlılık bozuk yük döndürürse, işlenmemiş istisnalar veya ham stack trace'ler dönmediğinden emin olun.

Düşük-değerli testler oluşturan yaygın tuzaklar

Düşük-değerli test setleri genellikle model hacim için ödüllendirildiğinde ortaya çıkar. Claude Code test oluşturma isteminiz "20 birim test" isterse, genellikle hiçbir yeni şey yakalamayan küçük varyasyonlar alırsınız.

Yaygın tuzaklar:

• Görünüşte farklı ama aynı olan testler: farklı string veya sayılarla aynı "geçerli girdi" testi tekrarları.
• Kodu aynalayan testler: gözlemlenebilir davranış yerine özel adımları veya yardımcı çağrıları assert etme.
• Her şeyi mock'lamak: veritabanı, saat, ağ ve konfigürasyonu hepsini değiştirmek.
• Zayıf assert'ler: sadece "hata yok", "null değil" veya "durum 200" kontrolü.
• Kirli paylaşılan durum: kalan seeded veriler, değiştirilmiş global'ler veya önbelleğe alınmış değerler.

Örnek: "kullanıcı oluştur" fonksiyonunu düşünün. On mutlu-yol testi e-posta stringini değiştirirken yine önemli şeyleri kaçırabilir: duplicate e-postaları reddetme, boş şifreyle başa çıkma ve döndürülen kullanıcı ID'lerinin benzersiz ve stabil olmasını sağlama gibi.

İnceleme için koruyucu kurallar:

• Her testin kapsadığı riski (sınır, hata modu veya invariant) isimlendirmesini zorunlu kılın.
• Gözlemlenebilir davranışı değiştirmediği sürede uygulama-özel kontrollerden kaçının.
• Mock'ları minimal tutun ve mümkünse gerçek entegrasyonu hedefleyen birkaç test bırakın.
• Güçlü assert'ler isteyin: kesin çıktılar, durum değişiklikleri ve hata tipleri/mesajları.
• Testlerin sıraya bağlı olmaması için temizleme kuralları ekleyin.

Örnek: bir özelliği küçük, güçlü bir test kümesine dönüştürme

Bir özellik düşünün: ödeme sırasında bir kupon kodu uygulama.

Sözleşme (küçük ve test edilebilir): bir sepet ara toplamını cent cinsinden ve isteğe bağlı bir kupon alarak cent cinsinden nihai toplam döndürsün. Kurallar: yüzde kuponlar en yakın cent'e aşağı yuvarlanır, sabit kuponlar sabit miktar düşer ve toplamlar asla 0'ın altına inmez. Bir kupon geçersiz, süresi geçmiş veya zaten kullanılmış olabilir.

"applyCoupon() için testler" demeyin. Bunun yerine bu sözleşmeyle bağlantılı sınır durumu testleri, hata modu testleri ve invariantları isteyin.

Kenar davranışları zorlamak için sınırlar

Matematiği veya doğrulamayı bozma eğilimindeki girdileri seçin: boş kupon stringi, subtotal = 0, minimum harcamanın hemen altı ve üstü, sabit indirim subtotal'dan büyük, ve 33% gibi bir yüzde yuvarlama yaratan değer.

Güvenli davranışı kanıtlamak için hata modları

Kupon araması başarısız olabilir ve durum yanlış olabilir: kupon servisi kapalı, kupon süresi geçmiş veya bu kullanıcı tarafından zaten kullanılmış. Test ne olduğunu kanıtlamalı (kupon reddedildi ve toplam değişmedi gibi).

Minimal, yüksek-sinyalli test seti (5 test) ve her birinin yakaladığı şey:

• Boş veya sadece boşluk içeren kodu reddetmek: boşu geçerli kabul eden hataları ve kötü trimlemeyi yakalar.
• Yüzde kupon yuvarlaması (subtotal 101, %33): yuvarlama hatalarını ve eksi-bir cent hatalarını yakalar.
• Sabit indirim subtotal'dan büyükse (subtotal 500, indirim 1000): toplamın negatif olmaması invariantını kanıtlar.
• Minimum harcama sınırı (subtotal 999 vs 1000): yanlış karşılaştırma mantığını (< vs <=) yakalar.
• Kupon arama hatası veya zaman aşımı: güvenli geri dönüşü (indirim uygulanmaz) ve stabil hata işleme gösterir.

Bunlar geçerse, çoğaltılmış mutlu-yol testleriyle dolu bir suite yerine ortak kırılma noktalarını kapsamış olursunuz.

Hızlı kontrol listesi: yüksek-sinyalli AI tarafından üretilen testler

Modelin ürettiklerini kabul etmeden önce hızlı bir kalite kontrolü yapın. Amaç, her bir testin sizi belirli, olası bir hatadan korumasıdır.

Bu kontrol listesini kapı olarak kullanın:

• Girdi başına sınırlar: her girdi alanı (stringler, ID'ler, zaman damgaları, bayraklar) için en az bir kenar durumu (boş vs sadece boşluk, max uzunluk, sıfır vs negatif, eksik opsiyonel alanlar, limitin bir fazlası) ekleyin.
• Bağımlılık hataları: bir bağımlılığın yanlış davrandığı en az bir testi dahil edin (veritabanı zaman aşımı, üçüncü taraf API 500, süresi geçmiş auth token). Güvenli davranışı kanıtlayın (açık hata, kısmi yazı yok).
• Invariantlar ile güçlü assert'ler: her zaman doğru kalması gereken 1–3 kural seçin ve doğrudan assert edin. "Yanıt iyi" gibi belirsiz assertlerden kaçının.
• Test başına bir benzersiz hata: her test başlığını okuyun ve "Bu test hangi kesin hatayı yakalar?" diye sorun. İki test aynı sorunun cevabını veriyorsa, birleştirin.
• Silme testi: bir testi silmeyi deneyin. Anlamlı hiçbir şey kaybolmuyorsa (ne sınır, ne hata modu, ne invariant), yerini hak etmemiştir.

Oluşturduktan sonra pratik numara: testleri "should <davranış> when <kenar koşul>" ve "should not <kötü sonuç> when <hata>" şeklinde yeniden adlandırın. Kolayca yeniden adlandıramıyorsanız, odaklanmamışlardır.

Koder.ai ile geliştiriyorsanız, bu kontrol listesi snapshot ve rollback ile güzel uyum sağlar: testleri üretin, çalıştırın ve yeni set ses gürültüsü eklemeden kapsama iyileştirmiyorsa geri alın.

Sonraki adımlar: bunu tekrarlanabilir bir iş akışı haline getirin

İsteminizi tek seferlik değil yeniden kullanılabilir bir çerçeve olarak ele alın. Sınırlar, hata modları ve invariantları zorlayan bir blueprint istemini kaydedin ve her yeni fonksiyon, endpoint veya UI akışı için tekrar kullanın.

Hızlı bir alışkanlık sonuçları hızla yükseltir: her test için bir cümlelik açıklama isteyin; eğer o cümle genelse, test muhtemelen gürültüdür.

Ürününüz için yaşayan bir domain invariantları listesi tutun. Kafanızda tutmayın. Gerçek bir hata bulduğunuzda ekleyin.

Tekrar eden hafif iş akışı:

• Küçük bir sözleşme çıkarın: girdiler, çıktılar, hata işleme ve 3–5 invariant.
• Blueprint istemini çalıştırın ve sınırlar, hata modları, invariantlar ile birlikte bir-satırlık gerekçeler isteyin.
• Farklı riskleri kapsayan en iyi 5–10 testi uygulayın.
• Refactor yapın, sonra yeni riskler görünüp görünmediğini görmek için istemi tekrar çalıştırın.
• Yinelenenleri budayın ve geçmişte olayları yakalayacak testleri tutun.

Eğer sohbet içinde uygulamalar inşa ediyorsanız, bu döngüyü Koder.ai (koder.ai) içinde çalıştırın ki sözleşme, plan ve üretilen testler tek bir yerde yaşasın. Bir refactor beklenmedik davranış değiştirirse, snapshot'lar ve rollback davranışı karşılaştırmayı ve yüksek-sinyalli set stabil hale gelene kadar yinelemeyi kolaylaştırır.