Specmatic'in kontrat testlerini "bitmiş" MERN stack Zerodha klonuma çalıştırdığım anda, araç manuel kontrollerimin asla yakalayamadığı beş gerçek hatayı tespit etti. Oluşturulan 178 test vakasından test paketi, API'yi gerçek kullanıcıları etkileyecek şekillerde bozdu: geçersiz veri türleri, hatalı biçimlendirilmiş kimlik bilgileri nedeniyle çökmeler, sessiz veri bozulması, idempotent olmayan kayıt işlemleri ve CI kapısını (CI gate) anında durduran bozucu bir kontrat değişikliği.

Hatalar manuel testlerden nasıl kaçtı

Proje; bir Node.js backend, bir React frontend, MongoDB depolama ve ödemeler için Razorpay'i birleştiriyordu. Kayıt olma ve ödeme akışlarını manuel olarak inceledim ve her şey çalışıyor gibi görünüyordu. Ancak manuel testler yalnızca "happy path"i (ideal senaryoyu) test eder: kodun, kullanıcılar amaçlanan adımları izlediğinde doğru çalıştığını onaylar. Servisin hatalı biçimlendirilmiş isteklere veya beklenmedik istemci davranışlarına karşı hayatta kalabileceğini kanıtlamaz.

Specmatic'i mevcut koda yönlendirdiğimde, her bir endpoint'in istek ve yanıt yapılarının açık bir tanımı olan kontrat, tek gerçeklik kaynağı (source of truth) olarak hizmet etti. Araç daha sonra, bir insan testçinin yazmayı asla düşünmeyeceği birçok pozitif ve negatif senaryodan oluşan devasa bir matrisi otomatik olarak oluşturdu.

Ortaya çıkan beş hata

  • Girdi doğrulama boşlukları – /newOrder endpoint'i, kontrat bir tam sayı (integer) gerektirmesine rağmen quantity alanı için ondalıklı sayılar ve dizeler (strings) kabul ediyordu. Yanlış türler gönderen oluşturulan testler, API'nin hatalı davranmasına neden oldu.
  • Ele alınmamış giriş hataları – Kimlik doğrulama rotasına hatalı biçimlendirilmiş kimlik bilgileri sağlanması, kodda tip kontrolleri eksik olduğu için bir çalışma zamanı (runtime) istisnasına yol açtı.
  • Sessiz ödeme bozulması – /verify-payment endpoint'i, amount için boolean değerlere izin veriyordu. Bir true değeri araya sızdığında, veritabanı sıfır değerine sahip başarılı bir ödeme kaydetti ve bu da gelir rakamlarını sessizce şişirdi.
  • Eksik idempotentlik (idempotency) – Test paketinde kayıt akışını ikinci kez çalıştırmak başarısız oldu; çünkü endpoint, mükerrer kullanıcıyı nazikçe işlemek yerine mevcut bir kullanıcıyı yeniden oluşturmaya çalıştı.
  • Yakalanan bozucu kontrat değişikliği – Kontratta kasıtlı olarak bir veri türünü değiştirdim. CI hattı (pipeline) değişikliği anında reddederek bozucu bir sürümün yayınlanmasını engelledi.

Kontrat testleri CI süreçleri (pipelines) için neden önemlidir?

  • Ölçeklenebilir negatif test – 178 vakanın çoğu uç durum (edge-case) girdileriydi. Bunları elle yazmak aşırı derecede zaman alıcı olurdu.
  • Üçüncü taraf istemciler için güvenlik – Kontratlar, bir servisin harici tüketicilere ne vaat ettiğini tanımlar. Uygulama (implementation) kontrattan saparsa, kontrat testi başarısız olur ve sonraki uygulamaları korur.
  • Hızlı geri bildirim döngüsü – CI kapısı, bozucu bir değişikliği birleştirilmeden (merge) önce durdurarak ekibi maliyetli bir geri alma (rollback) işleminden kurtardı.
  • İyileştirilmiş kod kalitesi – Bir actuator endpoint'i eklemek ve kayıt akışını idempotent hale getirmek, kontratı test edilebilir kılmak için gerekli adımlardı ve bu da servisi daha dayanıklı hale getirdi.

Geliştiricilerin tartması gereken ödünleşim (trade-off)

Kontrat testi bakım yükü getirir. Spesifikasyon kodla senkronize kalmalı ve test oluşturma süreci derleme sürelerini uzatabilir. Ekipler, özellikle manuel testlerin yeterli göründüğü daha küçük projelerde, eklenen güvenliğin bu ekstra çabaya değip değmeyeceğine karar vermelidir.

Sırada ne var?

  • Daha geniş CI adaptasyonu – Daha fazla ekip kontrat paketlerini süreçlerine entegre ettikçe, araçlar muhtemelen daha hızlı ve daha yapılandırılabilir hale gelecektir.
  • Standartlaştırılmış kontrat formatları – Gelişmekte olan spesifikasyonlar, kontratların servisler ve ekipler arasında paylaşılmasını kolaylaştırabilir.
  • Spesifikasyon güncellemelerinin otomasyonu – Kontratları kod değişikliklerinden çıkaran araçlar, manuel bakım yükünü azaltabilir.

Eğer UI sorunsuz çalıştığı için API'nizin sağlam olduğunu varsayarsanız, bir kontrat testi çalışması manuel kontrollerin gözden kaçırdığı gizli hataları ortaya çıkarabilir. CI sürecinize yürütülebilir bir kontrat eklemek, "iyi görünüyor" ifadesini "güvenli olduğu kanıtlanmış" ifadesine dönüştürür.

Repository: https://github.com/priya3054/zerodha-specmatic