19 Ara 2025·6 dk
Sınır durumu testleri için Claude Code test oluşturma istemi
Sınırları, invariantları ve hata modlarını hedefleyerek mutlu-yol yerine yüksek-sinyalli testler üreten bir Claude Code test oluşturma istemini öğrenin.
Sınırları, invariantları ve hata modlarını hedefleyerek mutlu-yol yerine yüksek-sinyalli testler üreten bir Claude Code test oluşturma istemini öğrenin.
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 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.
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.
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.
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?
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:
Bu üç hedefe odaklandığınızda, daha az testiniz olur ama her biri daha fazla sinyal taşır.
Ç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.
Sözleşmeyi düz dilde, kod değil şekilde yazın ve yalnızca test edebileceğiniz şeyleri dahil edin.
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.
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:
| Dimension | Valid edge | Just outside | “Weird” value | Expected behavior |
|---|---|---|---|---|
| length | 0 | -1 | 10,000 | error vs clamp vs accept |
Eğer Claude 20 test önerirse, geri ittirin. Benzer vakaları birleştirmesini ve sadece gerçek bir hatayı yakalayacak olanları tutmasını isteyin.
İ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ı:
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.
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ı 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:
Ş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.
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:
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:
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:
Ö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 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:
Ö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:
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.
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.
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:
Bunlar geçerse, çoğaltılmış mutlu-yol testleriyle dolu bir suite yerine ortak kırılma noktalarını kapsamış olursunuz.
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:
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.
İ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ışı:
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.
Default: aim for a small set that would catch a real bug.
A quick cap that works well is 6–10 tests per unit (function/module). If you need more, it usually means your unit is doing too much or your contract is unclear.
Happy-path tests mostly prove that your example still works. They tend to miss the stuff that breaks in production.
High-signal tests target:
Start with a tiny contract you can read in one breath:
Then generate tests from that contract, not from examples alone.
Test these first:
Pick one or two per input dimension so each test covers a unique risk.
A good failure-mode test proves two things:
If there’s a database write involved, always check what happened in storage after the failure.
Default approach: turn the invariant into an assertion on observable outcomes.
Examples:
expect(total).toBeGreaterThanOrEqual(0)Prefer checking both and , because many bugs hide in “returned OK but wrote the wrong thing.”
It’s worth keeping a happy-path test when it protects an invariant or a critical integration.
Good reasons to keep one:
Otherwise, trade it for boundary/failure tests that catch more classes of bugs.
Push for PHASE 1: plan only first.
Require the model to provide:
Only after you approve the plan should it generate code. This prevents “20 look-alike tests” output.
Default: mock only the boundary you don’t own (DB/network/clock), and keep everything else real.
To avoid over-mocking:
If a test breaks on refactor but behavior didn’t change, it’s often over-mocked or too implementation-coupled.
Use a simple deletion test:
Also scan for duplicates: