# Production Hatasını Hangi Test Engeller?

> Unit ve integration testlerin gerçek getirisi: hangisinin production hatalarını gerçekten önlediği ve test bütçesinin nereye ayrılacağı.

- Tür: Denemeler
- Yayın: 2026-10-24
- Etiketler: testing, quality, opinion
- Okuma süresi: 2 dk okuma
- Kaynak: https://muhammetsafak.com/tr/muhendislik/denemeler/integration-vs-unit-test/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
> **Kısaca:** Pratikte production hatalarının birçoğu bileşenlerin arasında doğar ve izole bir unit test tam da kırılan bağlantıyı mock'lar. Unit test saf, mantık yoğun çekirdekte parlar; integration test glue code'u gerçek veritabanı ve HTTP katmanıyla sınar. Test bütçesini hataların doğduğu yere ayırın, mock'u yalnızca ödeme sağlayıcısı gibi dış bağımlılıklara saklayın.

%100 unit test coverage'ı olan bir özellik, production'da ilk gün kırıldı. Hata hiçbir birimin içinde değildi; iki bileşenin birbiriyle konuşma biçimindeydi. Her birim tek tek, izole, kusursuz test edilmişti. İkisinin arasındaki dikişi ise hiçbir test görmemişti.

"Hangi test bu hatayı engellerdi?" sorusu, test stratejisinin asıl sorusudur.

## Gerçek hatalar nerede doğar

Production hatalarını dürüstçe geriye doğru izlerseniz, birçoğunun aynı yerde buluştuğunu görürsünüz: bileşenlerin **arası**. Yanlış serialize edilmiş bir payload, uyuşmayan bir kontrat, yanlış çizilmiş bir transaction sınırı, ortamlar arası bir config farkı.

İzole unit test, tam da kırılan o parçayı mock'lar. Veritabanını mock'layan bir test, yanlış yazılmış bir sorguyu göremez. HTTP katmanını mock'layan bir test, yanlış bir status kodunu yakalayamaz. Test, gerçeğin yerine koyduğu sahte şey kadar iyidir.

## Unit test ne işe yarar

Bu, unit test'e karşı bir yazı değil. Unit test'in net bir değeri var: karmaşık, saf mantık üzerinde hızlı geri bildirim. Bir hesaplama, bir algoritma, bir durum makinesi, bir sürü edge case — bunları izole, hızlı testlerle sınamak doğru hamledir. Saniyeler içinde yüzlerce senaryo.

Unit test, **mantık** zengin olduğunda parlar.

## Integration test ne işe yarar

Integration test farklı bir soruyu cevaplar: bileşenler gerçekten birlikte çalışıyor mu? Gerçek veritabanıyla, gerçek HTTP katmanıyla, gerçek kuyrukla. Bir endpoint'e istek atıp veritabanında doğru satırın oluştuğunu doğrulamak — mock'ların gizleyeceği her şeyi açığa çıkarır.

Tipik bir web uygulaması çoğunlukla **glue code**'dur: veriyi al, doğrula, kaydet, döndür. Bu kodun içinde az mantık, çok bağlantı vardır. Bağlantıyı ancak integration test sınar.

## Test bütçesi nereye

Klasik test piramidi en alta çok sayıda unit test koyar. Ama tipik bir web uygulaması için, hata önleme açısından en yüksek getiriyi integration testler verir — çünkü hatalar bağlantıda doğuyor.

Pratik dağılım: glue code için integration test; mantık yoğun çekirdek için unit test. Glue code'a izole unit test yığmak, [coverage sayısını](/tr/muhendislik/denemeler/sade-test-kulturu/) yükseltir ama production'ı korumaz.


> **Tan:** Bir hata production'a kaçtığında, onu hangi testin yakalayacağını yazın: unit mi, integration mı? Birkaç olay sonra test bütçesinin nereye gitmesi gerektiği tartışma değil, bir kayıt olur. Yazının başındaki soru, her post-mortem'in son maddesi olabilir.


## Mock'un tuzağı

En sık hata, kırılan şeyi mock'lamaktır. Bir sorgunun yanlış olduğunu, veritabanını mock'layan bir test asla söyleyemez — çünkü o test, sorgunun gittiği yeri sahteyle değiştirmiştir. [Veri yoğunluklu sistemlerdeki](/tr/muhendislik/sistemler/veri-yogunluklu-sistemler-kirilma-noktalari/) N+1 gibi bir sorgu hatası, ancak gerçek veritabanına giden bir test ile yakalanır.

Mock'u, kontrol edemediğiniz ve yavaş olan dış şeyler için saklayın — bir ödeme sağlayıcısı gibi. Kendi veritabanınızı mock'lamak, çoğu zaman testi gerçeklikten koparmaktır.

---

"Bütün testler yeşil" cümlesi, "production güvende" demek değildir. Hangi testin hangi hatayı engellediğini bilmiyorsanız, test sayınız bir güven kaynağı değil, bir histir.

Test bütçenizi, hataların gerçekten doğduğu yere — bileşenlerin arasına — ayırın.

## Kaynaklar

- [TestPyramid](https://martinfowler.com/bliki/TestPyramid.html) — martinfowler.com