Test nedir ve neden gereklidir?

Claude Code kodu değiştirdi ve "Testler geçti" yazdı. Bu kısa ifadenin ardında kontrol içeren dosyalar, çalıştırma komutu ve somut sonuçlar var. Önce test türlerine ve elle neleri kontrol edebileceğinize bakalım; ardından otomatik testi ve sonucunun ne anlama geldiğini ele alalım.

Bunun için puan hesaplayan küçük bir örnek yeterli. Test kütüphanelerini önceden bilmeniz gerekmiyor: önce senaryoyu elle uygulayacağız, sonra otomatik testler için beklentileri tanımlayıp çalıştırma raporunu inceleyeceğiz.

Test türleri

Test etmek, programın nasıl davrandığını, gereksinimleri karşılayıp karşılamadığını ve sorunların nerede çıktığını anlamaya yardımcı olur. Örneğin, puanlar doğru hesaplanıyor mu, boş alan içeren bir başvuru gönderilebiliyor mu, hata mesajı anlaşılır mı? Bunun için kontrol koşullarını belirler, adımları uygular ve sonucu inceleriz.

Testleri farklı ölçütlere göre sınıflandırabiliriz. Önce adımları kimin uyguladığına ve sonucu kimin kontrol ettiğine bakalım:

• manuel test - kontrolü kişi kendisi yapar ve sonucu değerlendirir;
• test otomasyonu - bazı kontroller programa verilir: program belirlenen adımları uygular ve karşılaştırmaları yapar. Bu kontrollere genellikle otomatik test denir.

Bu, testin nasıl yapıldığına göre bir ayrım. Bir de başka bir soru var: tam olarak neyin kontrol edildiği. Fonksiyonel testler davranışla ilgilidir: örneğin, hak edilen puanlar verildi mi? Fonksiyonel olmayan testler uygulamanın çalışma özelliklerine bakar: örneğin, ne kadar hızlı yanıt verdiği ya da kullanımının ne kadar kolay olduğu. Bu ölçütler birbirinden bağımsızdır: aynı işlevi hem elle hem de otomatik olarak kontrol edebilirsiniz.

Otomasyon, insanın sürece katılımını ortadan kaldırmaz. Yine de işe yarar senaryoları seçmek, beklentileri belirlemek ve bulunan farklılıkları anlamak gerekir. İşin tekrarlanan kısmını ise program üstlenir.

Manuel test nedir?

Manuel testte adımları kendiniz uygular ve sonucun beklentinizi karşılayıp karşılamadığına bakarsınız. Bunun için test kodu yazmanız şart değil. Anlaşılır koşullar ve yanıtını aradığınız bir soru yeterli.

Bir eğitim portalında her eşleşme için 10 puan verildiğini varsayalım; üç eşleşme 30 puan eder. Puanların doğru hesaplandığını elle şöyle kontrol edebilirsiniz:

1. portalın gereken sürümünü açın ve bakiyesi sıfır olan, henüz ödül almamış bir kullanıcı hazırlayın;
2. üç eşleşme içeren bir başvuru hazırlayıp bir kez gönderin;
3. gönderimden sonra bakiyeye bakın: 30 puan bekleniyor;
4. gerçek sonucu kaydedin. Farklı bir sayı çıktıysa adımları, gerekirse ekran görüntüsünü de saklayın.

Başlangıç bakiyesi burada önemli. Kullanıcının zaten 20 puanı varsa, ödül eklendikten sonra 30 değil 50 beklemeniz gerekir. Başlangıç koşulları bilinmezse doğru sonucu hata sanmak ya da hatayı doğru sonuç sanmak kolaydır.

Kontrol sonucunu kısaca şöyle yazabilirsiniz: "Gönderimden önce bakiye 0, üç eşleşme, bir gönderim, beklenen 30, alınan 3". Bu notu gören başka biri ya da Claude Code neyi tekrarlaması gerektiğini anlar. "Puanlar tuhaf çalışıyor" demek bunu açıklamaz.

Manuel test keşif amaçlı da olabilir: uygulamayı incelerken yeni kontroller tasarlarsınız. Örneğin, gönderimden sonra düğmenin hâlâ etkin olduğunu fark edip yeniden tıklamayı denersiniz. Burada adımları önceden tek tek belirlenmiş bir rota yoktur, ama amaç bellidir: davranışı anlamak ve bulduğunuz sorunları kaydetmek. Rastgele tıklamak değil.

Bu sırada araç kullanmanızda sakınca yok. Tarayıcı konsolunu açabilir, sunucunun yanıtına bakabilir, ekran görüntüsü alabilir ya da kontrollerinizi listeleyebilirsiniz. "Manuel" denmesi, kişinin kontrolü yönetip sonucu değerlendirdiği anlamına gelir; araçsız çalışması gerektiği anlamına değil.

Yeni bir davranışı araştırırken veya arayüzün anlaşılır olup olmadığını değerlendirirken manuel kontrol işe yarar. Daha önce tanımlanmış adımları ve karşılaştırmaları tekrar tekrar yapmak için otomatik test kullanışlıdır. Bu, "arayüz sadece elle, hesaplamalar sadece kodla" gibi katı bir ayrım değildir: tarayıcıdaki adımlar da otomatikleştirilebilir, hesaplama da elle kontrol edilebilir.

Otomatik testleri başlatan düğmeye basmak henüz manuel test sayılmaz: çalıştırdıktan sonra kontrolleri program yapar. Claude Code size adımları sıraladıysa ve siz portalda bu adımları izleyip sonucu değerlendirdiyseniz, kontrol yine manueldir. Ajan yalnızca hazırlanmasına yardımcı olmuştur.

Otomatik test nedir?

Bir hesap makinesini kontrol ettiğinizi düşünün. 2 + 2 giriyor, sonucun 4 olmasını önceden bekliyor ve ekrandaki sayıyı bu beklentiyle karşılaştırıyorsunuz. 5 görürseniz, bu örnekte sonucun yanlış olduğunu anlarsınız. Hesap makinesinin ne gösterdiğinden bağımsız olarak doğru yanıtı biliyorsunuz.

Otomatik test benzer işi program aracılığıyla yapar. Başlangıç koşullarını belirleyen, bir işlem yapan ve sonucu kontrol eden küçük bir programdır. Karşılaştırmayı kişi yerine kod yapar. Bundan sonra bu tür otomatik testlere kısaca test diyeceğiz.

Ödül portalına dönelim: her eşleşme 10 puan getiriyor, üç eşleşme için 30 puan veriliyor. Kontrolü sözcüklerle şöyle tarif edebiliriz:

1. eşleşme sayısını 3 olarak ayarlayın;
2. ödül hesabını çalıştırın;
3. ödül miktarının 30 olduğunu kontrol edin.

İşte bu, tek bir test olur. Önceden bilinen bir örnek ve beklenen yanıt vardır. "Eşleşme başına 10 puan" kuralı bizim eğitim portalımız için geçerli; başka bir uygulamada farklı olabilir.

Test, kullanıcıya kaç puan verilmesi gerektiğini kendi başına belirlemez. Gereksinimdeki kuralı alıp beklentiyi yazacak birine ihtiyaç var. Bunu bir geliştirici ya da sizin isteğinizle Claude Code yapabilir, ama beklentinin görevle örtüştüğünü yine de kontrol etmelisiniz.

Kontrolü neden tekrarlamak gerekir?

Puan hesaplamasını bir kez elle kontrol etmek oldukça kolaydır. Sorun daha sonra çıkar: yeni bir ödül türü eklediniz, başvuru işleme biçimini değiştirdiniz ya da ajandan işlevi basitleştirmesini istediniz. Her değişiklikten sonra aynı soru akla gelir: üç eşleşme hâlâ 30 puan ediyor mu?

Her seferinde başvuruyu yeniden hazırlayıp adımları uygulayabilir ve sonucu inceleyebilirsiniz. Ya da bu kontrolü koda yazıp tekrar çalıştırabilirsiniz. Aynı koşullar hazırlandığında test, tanımlı adımları ve karşılaştırmayı yeniden yapar. Nereye tıklanacağını ve neyin doğru sayılacağını baştan anlatmanız gerekmez.

Proje büyüdükçe bu kuralların sayısı da artar. Boş başvuru puan eklememeli; aynı başvuru iki kez hesaba katılmamalı; ödül listesi belirli bir sırada olmalı. Kontrolleri birlikte çalıştırıp değişiklikten sonra hangi beklentinin artık karşılanmadığını görebilirsiniz.

Otomasyonun yararı burada: tanımlanmış bir davranışı tekrar kontrol etmek için daha az elle uğraşırsınız. Testleri yazmak da zaman alır, gereksinimler değiştiğinde testleri gözden geçirmek gerekir. Yine de sık sık geri döndüğünüz kurallar için bu emek, testleri yeniden çalıştırdıkça karşılığını verir.

Testler nerede bulunur?

Testler projenin sıradan dosyalarında saklanır. Küçük bir JavaScript projesinde kontrolü, çağırdığı kodun yanına koymak kullanışlıdır:

reward-example/
├── package.json
└── src/
    ├── reward-flow.js
    └── reward-flow.test.js

reward-flow.js ödül hesabını içerir. reward-flow.test.js bu hesabı çağıran ve yanıtı kontrol eden koddur. package.json dosyası, test komutu dahil olmak üzere proje ayarlarını ve komutlarını tanımlar.

Dosya adındaki .test.js bölümü, bunun bir test dosyası olduğunu anlamanıza yardımcı olur. Bu, test araçlarının desteklediği bir adlandırma geleneğidir; JavaScript dilinin ayrı bir kuralı değildir. Başka projelerde farklı adlar ya da ayrı bir tests/ klasörü kullanılır. Bir dosya birden çok test içerebilir; her kaynak dosyanın yanında ayrı bir test dosyası olması şart değil.

Claude Code bilmediğiniz bir projede çalışıyorsa önce puan hesabını kontrol eden mevcut testi bulmasını ve yolunu göstermesini isteyin. Böylece tüm klasörlere henüz hâkim olmasanız da kontrolü doğru davranışla ilişkilendirebilirsiniz.

Niyet teste nasıl dönüştürülür?

"Puan hesabını düzelt ve testlerle kontrol et" isteği ajanı aynı anda iki soruyla baş başa bırakır: doğru puan hesabı nedir ve sonucu neyle doğrulamalı? Önce elde etmek istediğiniz davranışı tarif edin. Örneğin: "Her eşleşme için 10 puan verilir. Üç eşleşmede ödül 30 puan olmalı".

Bu niyeti tek satır kod yazmadan teste dönüştürebilirsiniz. Üç şeyi açıklayın:

Bunu tek cümlede şöyle söyleyebiliriz: "Üç eşleşme varsa ödül hesabı 30 puan vermeli". Testin ne anlama geldiğini konuşmak için bu bilgi yeterli. Bu projede kontrolün hangi kodla yazılacağını ajan kendisi çözer.

Neyi doğrulamak istediğinizi netleştirmek önemli. "Ödül 30 olarak hesaplandı" ile "kullanıcının bakiyesi 30 oldu" farklı beklentilerdir. İkincisi için yukarıdaki manuel kontrolde olduğu gibi başlangıç bakiyesi ve puan ekleme işlemi gerekir. Bu nedenle "puanları kontrol et" demek yerine gözlemlenecek sonucu açıkça belirtin.

Ardından yakın senaryoları düşünün. Bu kural için küçük bir tabloyla başlamak yeterli:

Hemen onlarca durum bulmanız gerekmiyor. Soruna yol açan senaryodan ve değişikliğin etkileyebileceği birkaç yakın durumdan başlayın. Örneğin, aynı başvuru ikinci kez gönderildiğinde ne olması gerektiği belli değilse önce kuralı netleştirin. Ajan bir seçenek önerebilir ama bu henüz üzerinde anlaşılmış bir beklenti değildir.

Kontrol Claude Code'a nasıl devredilir?

Beklenen davranışı tanımladıktan sonra çalışmayı bunun etrafında düzenleyebilirsiniz. Önce ajan projede hangi kontrollerin bulunduğunu öğrenir, ardından bunları senaryolarınızla karşılaştırır. Gerekli kontrol zaten var olabilir; bu durumda onu çalıştırıp sonucu okumak önemli. Yoksa ajanın bir test eklemesi gerekir.

İlk isteğiniz şöyle olabilir:

Ödül hesabının düzeltilmesi gerekiyor.
Kural: Her eşleşme için 10 puan verilir.
Kontrol edilecek durumlar: 3 eşleşme 30 puan verir,
0 eşleşme 0, 5 eşleşme 50 puan verir.

Değişiklik yapmadan önce bu durumlar için mevcut kontrolleri bul.
Şu anda nelerin kontrol edildiğini, nelerin eksik olduğunu
ve hangi testleri eklemeyi ya da değiştirmeyi önerdiğini
kısaca açıkla. Gereksinimler belirsizse belirt.
Şimdilik dosyaları değiştirme.

Yanıtı, ortaya çıkması beklenen sonucun açıklaması gibi okuyun. Her durumdaki sayılar sizin kuralınızdan mı geliyor? Gerçekten ödül miktarı mı kontrol ediliyor, yoksa başka bir şey mi? Mevcut davranışa uysun diye kuralı değiştirme önerisi var mı? Bu aşamada görevi netleştiriyorsunuz; testin kodunu okumanız gerekmiyor.

Senaryoları netleştirdikten sonra işi yapmasını isteyin:

Ödül hesabını konuştuğumuz kurala göre düzelt.
Üzerinde anlaştığımız durumlar için eksik kontrolleri,
projede kullanılan araçlarla ekle.
Mevcut beklentileri başarılı bir test çalıştırması uğruna değiştirme.
Bir beklentinin yanlış olduğunu düşünüyorsan önce nedenini açıkla.

Proje yönergelerine göre gerekli testleri çalıştır.
Komutu, çalışma klasörünü ve gerçek çıktıyı göster.
Üç durumun her biri için hangi testin kontrol ettiğini
ve nasıl sonuçlandığını belirt. Atlanan ve çalıştırılmayan
kontrolleri ayrıca listele.

Ajan çalıştırma komutunu proje belgelerinde ve ayarlarında bulur. JavaScript projelerinde bu genellikle npm test olur: npm, package.json dosyasındaki scripts.test alanında tanımlı komutu çalıştırır. Bu adın arkasında farklı kontroller bulunabilir. Sizin yapmanız gereken, çalıştırmaya istediğiniz senaryoların dahil olduğunu doğrulamak.

Testin yazılmasıyla çalıştırılması farklı aşamalardır. "Üç kontrol ekledim" mesajı yalnızca dosyalardaki değişiklikleri anlatır. Sonucu değerlendirmek için testi gerçekten çalıştırmak gerekir. Örneğin eksik bir bağımlılık yüzünden çalıştırılamıyorsa ajan neyin engel olduğunu ve hangi kontrollerin yapılmadığını belirtmeli.

Yanıtta "senaryomuz → belirli test → sonuç" bağlantısını arayın. Konuştuğunuz üç durumdan yalnızca biri çalıştırıldıysa şimdilik sadece o doğrulanmıştır. Son satır yeşil görünse bile.

Sonuç nasıl okunur?

Aşağıda Node.js 20.18.0 ve npm 10.8.2 ile tek bir eğitim testinin gerçek çalıştırması yer alıyor. Bu test yalnızca üç eşleşmenin ödül hesabını kontrol ediyor; yukarıdaki senaryoların tamamını değil. Okumayı kolaylaştırmak için süre satırları ve raporun yardımcı bölümleri çıkarıldı:

> reward-example@1.0.0 test
> node --test --test-reporter=tap

# Subtest: three matches give 30 points
ok 1 - three matches give 30 points

# tests 1
# suites 0
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0

İlk iki satır paketi ve çalıştırılan komutu gösterir. Sonraki satır testin adıdır. ok 1 satırı 1 numaralı testin geçtiği anlamına gelir; başarısız testte satır not ok ile başlar. pass 1 ve fail 0 satırları bir testin geçtiğini ve hiçbirinin başarısız olmadığını söyler. Terminal metni renklendirmese de buna "yeşil" sonuç denir.

Hatalı sürümde, üç eşleşme için kural 30 puan öngörmesine rağmen ödül 3 puan çıkar. Aynı test şu bölümü üretir; dosya yolu, çağrı yığını, süre ve yardımcı satırların bir kısmı çıkarıldı:

not ok 1 - three matches give 30 points
  error: |-
    Expected values to be strictly equal:

    3 !== 30

  code: 'ERR_ASSERTION'
  name: 'AssertionError'
  expected: 30
  actual: 3
  operator: 'strictEqual'

# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0

Önce testin adını bulun, sonra expected ve actual değerlerini karşılaştırın. İlki "beklenen", ikincisi "alınan" demektir. Burada 30 beklenmiş, 3 alınmış. fail 1 satırı sonucu özetler: bir test başarısız oldu.

Bu başarısızlık, alınan değerin yazılı beklentiyle eşleşmediğini gösterir. Sonraki adım nedeni bulmak: hesaplama hatalı olabilir, başlangıç verileri yanlış olabilir ya da testteki beklenti hatalı olabilir. Rapor başarılı görünsün diye kontroldeki sayıyı değiştirmeyin; önce görevdeki kuralı doğrulayın.

Başka türde bir başarısızlık da olabilir: örneğin test, işlev dosyasını yükleyemeyebilir. Bu durumda puanları karşılaştırmaya hiç geçilmez, hatta raporda ilgili testin adı bile olmayabilir; başarısız olarak tüm dosya işaretlenir. Bu nedenle yalnızca fail 1 satırına bakıp "hesaplama yanlış" sonucuna varamazsınız. Özetin üstündeki mesajı okuyun.

Atlanan test

Testin önemli bir durumu daha var. Bir kontrol atlanacak şekilde işaretlenebilir; Node.js'te bunu örneğin test.skip ile yaparsınız. Bu test çalıştırılmaz. Adının raporda görünmesi, senaryonun kontrol edildiği anlamına gelmez.

Örneğimizin ayrı bir çalıştırmasında atlanan test şu satırı ve özeti verdi:

ok 1 - three matches give 30 points # SKIP

# tests 1
# pass 0
# fail 0
# cancelled 0
# skipped 1
# todo 0

Alışılmadık bir ayrıntıya dikkat edin: satır ok ile başlıyor ama # SKIP ile bitiyor. Bu biçim, atlanan testi böyle işaretliyor. Yalnızca ilk sözcüğe bakmayın; pass 0 özeti, burada geçen test olmadığını doğruluyor.

Aynı senaryonun üç çalıştırmasını yan yana koyalım:

Daha büyük raporlarda başka satırlar da bulunur. Örneklerimizde cancelled ve todo değerleri sıfır. Sıfırdan farklı değerler görürseniz hangi testlerin iptal edildiğini ya da tamamlanmamış olarak işaretlendiğini öğrenin; bunları başarıyla kontrol edilmiş saymayın. suites satırı test gruplarıyla ilgilidir; örneğimizde grup yok.

Küçük bir ayrıntı daha. Rapor sıfır test gösteriyorsa, hiçbir testin başarısız olmaması puan hesabını doğrulamaz. Gerekli kontrol çalıştırmaya dahil edilmemiş olabilir. Senaryonun adına ve çalıştırılan test sayısına bakmak, terminalin rengiyle ilgili genel izlenimden daha önemlidir.

Yeşil sonuç ne anlama gelir?

Gösterilen rapordaki test dar kapsamlı bir soruyu yanıtladı: "Üç eşleşme için ödül doğru hesaplandı mı?" Sıfır eşleşmeyi, yinelenen başvuruyu ya da sayfadaki sayıyı kontrol etmedi. Bir istekte bu durumlardan söz etmiş olmanız, onların test edildiği anlamına gelmez.

Sıfır eşleşmeyi kontrol etmek için beklenen sonucu 0 olan ayrı bir senaryo gerekir. Yinelenen başvuruyu kontrol etmek için tekrar gönderme adımını ve beklenen sonucu tanımlamalısınız. Test bu kuralları yakındaki koddan çıkaramaz. Yalnızca içine yazılanlar kontrol edilir.

Testin hiç olmamasıyla testin atlanması farklıdır. Atlanan test raporda skipped olarak görünür. Kontrolü hiç yazılmamış bir senaryodan ise rapor genellikle söz etmez. Kontrol edilmeyen davranışta hata olsa bile mevcut tüm testler geçebilir.

Son olarak, karşılaştırmanın başarılı olması beklentinin kendisini doğru yapmaz. Kuralımız için yanlışlıkla 30 yerine 3 yazılır ve hesaplama da 3 verirse karşılaştırma geçer. Bu yüzden testi konuşurken şu iki soruyu yanıtlamak yararlı olur: Test hangi davranışı kontrol ediyor ve beklenen sonuç nereden geliyor?

"Testler geçti" ifadesi, sınırlarını anladığınızda işe yarar. Belirli bir çalıştırmada belirli kontrollerin başarıyla tamamlandığını söyler. "Uygulamada artık hiç hata yok" vaadinde bulunmaz.