🔌 API Testinde Claude

API Testinde Claude: Claude'a yapıştırılan bir response JSON'ından API test assertion'ları yazdırmak, bir müfettişten TEK bir bitmiş odanın fotoğraflarını gördükten sonra bir yap

Claude'a yapıştırılan bir response JSON'ından API test assertion'ları yazdırmak, bir müfettişten TEK bir bitmiş odanın fotoğraflarını gördükten sonra bir yapı yönetmeliği kontrol listesi yazmasını istemeye benzer — mekanizma birebirdir: fotoğraf, yanıtın o an nasıl göründüğünü gösterir (gerçek JSON), ama iyi bir assertion seti odanın DOĞRU bitmediğinde (eksik bir alan, yanlış bir tip, bir hata durumu) ne olacağını da kapsamalıdır — bu bilgiyi mutlu yol yanıtının tek başına asla göstermediği bir şey. Üzerinde durulmaya değer soru şu: Claude senin 200 OK JSON'ını okuyup içindeki her alan için kusursuz assertion yazabiliyorsa, o set neden hâlâ eksik? Çünkü sadece mutlu yolu gördü — ona bir 422 doğrulama hatasının veya bir 500'ün neye benzediğini kimse göstermedi, o yüzden hiç görmediği hata şekilleri üzerine assertion yazamaz; bu senaryoları sen sağlamalı veya açıkça istemelisin. Java karşılaştırması: bu, gerçek API kontratından (OpenAPI spec) değil, tek bir geçen koşumun kaydedilmiş çıktısından JUnit assertion'ları yazmak gibidir — bir kere olanı kusursuzca test edersin ama kontratın edge case'ler için gerçekte vaat ettiğini kaçırırsın. QA tarafındaki bedel: %100 yeşil ama dokümante edilmiş bir 400/401/404/500 davranışını hiç doğrulamamış bir API seti, tam olarak gerçek production olaylarının (kötü girdi, auth hataları, downstream timeout'lar) yaşandığı yerde sahte güven verir.

Response JSON'ından Gerçek Assertion'lara

Gerçek bir yanıt yapıştır ve açık kısıtı ekle: "X geçersiz girdi için ne olacağını da sor" — Claude bundan sonra mutlu yol için alan alan assertion önerir ve istenirse, gerçek kontratı onayladıktan sonra da doğrulanacak olası 4xx/5xx şekillerini hipotez eder.

Akıl yürütme: neden endpoint'i sadece kelimelerle anlatmak yerine OpenAPI spec'ini yapıştırasın? Bir OpenAPI tanımı zaten Gherkin ile aynı Given/When/Then tarzı zorlayıcı mekanizmadır — her parametreyi, zorunlu/opsiyonel bayrağını ve response şemasını açıkça isimlendirir, tam olarak Test Case Üretimi sekmesinde tartışılan türden oracle belirsizliğini ortadan kaldırır. OpenAPI spec'in yoksa endpoint'i gayriresmi olarak anlatmak da işe yarar, ama Claude'un çıktısının daha fazlasının onaylanmış kural yerine işaretli varsayım olmasını bekle.

given().when().then() Zinciri Aslında Ne Zaman Neyi Kontrol Eder?

given().header(...) satırı HENÜZ…

given().header(...) satırı HENÜZ hiçbir İSTEK GÖNDERMEZ — sadece isteğin HAZIRLIK aşamasında hangi header/parametrelerin ekleneceğini TANIMLAR.

when().get("/api/users/{id}", 42) çağrıldığı ANDA…

when().get("/api/users/{id}", 42) çağrıldığı ANDA gerçek HTTP isteği GÖNDERİLİR — {id} yer tutucusu 42 değeriyle DOLDURULUR ve istek /api/users/42'ye GİDER.

then().statusCode(200) YANIT geldikten SONRA…

then().statusCode(200) YANIT geldikten SONRA çalışır ve HTTP durum kodunu KONTROL eder — bu kontrol FAIL olursa sonraki .body(...) satırları HİÇ ÇALIŞTIRILMADAN test başarısız SAYILIR.

.body("id", equalTo(42)) ve .body("email", ...)…

.body("id", equalTo(42)) ve .body("email", notNullValue()) ZİNCİRLEME olarak AYNI yanıt gövdesi üzerinde birden fazla bağımsız kontrol YAPAR — her biri kendi JSON path'ini SORGULAR.

// Not yet confirmed satırındaki yorum…