Nihai Tutarlılık: Senkron E2E Testi Tam Burada Çöker

"Siparişi Gönder"e tıkla, bekle, sonra order.status == 'COMPLETED' doğrula. Yerel ortamında pürüzsüz çalışır. CI'da her altı koşudan birinde patlar.

Tipik ekip refleksi: "yeniden çalıştır gitsin, kırılgan testtir herhalde." Ama retry'a basmak hiçbir şeyi düzeltmez. Sadece mimari bir gerçeği halının altına süpürür. Asenkron ve nihai tutarlı (eventually consistent) bir sistemi senkron varsayımlarla test etmeye çalışıyorsun.

Olay Güdümlü Sistemlerde Kör Nokta

ACID işlemli bir monolitte durum değişiklikleri anlık ve öngörülebilirdir. Modern dağıtık sistemlerde ise bir butona tıklamak durumu nadiren senkron olarak değiştirir. Kafka, RabbitMQ ya da SQS gibi bir mesaj brokerına bir olay yayınlar.

Alt taraftaki tüketici grupları (consumer groups) mesajı alır, iş mantığını uygular ve durumu asenkron olarak işler. Bunun küme yükü altında 100ms, 500ms ya da iki saniyede tamamlanacağına dair matematiksel hiçbir garanti yoktur. Ekipler asenkron mekaniğe dair sistem okuryazarlığından yoksun olduğunda üç hata modu ortaya çıkar.

Mantık Yerine Gecikmeyi Test Etmek

Körlemesine timeout eklemek veya arayüzü sürekli yoklamak (polling), testlerinin doğruluğu değil ağ dalgalanmasını ve broker kuyruk gecikmesini ölçmesi demektir; sonra da bunu bir ürün hatasıymış gibi raporlar.

Idempotency'yi Görmezden Gelmek

En-az-bir-kez teslimat (at-least-once) altında ağ bölünmeleri retry'a yol açar. Bir tüketici aynı olayı iki kez alırsa, sistemin bunu tekilleştiriyor (deduplicate) mu, yoksa müşteriyi sessizce iki kez mi ücretlendiriyor? Kara kutu testler tüketici tarafı idempotency'yi neredeyse hiç test etmez, çünkü yalnızca mutlu yolun tek emisyonunu simüle eder.

Poison Pill ve DLQ Körlüğü

Bir mesaj doğrulamadan geçemediğinde, partition durur mu, yoksa mesaj bir ölü mektup kuyruğuna (DLQ) yönlenirken servis işlemeye devam mı eder? Test paketin broker durumunu ya da consumer lag'i inceleyemiyorsa, hata kurtarmayı (fault recovery) doğrulaman mümkün değildir.

Sadece Veritabanını Değil, Kuyruğu da Gözle

Nihai tutarlılık, koda gömülü sleep'lerle savaşılacak bir hata değil, bir mimari modeldir. Test koşum aracını arayüzü yoklamak yerine doğrudan olay-tamamlanma konularına (topic) abone et. Yinelenen olayları bilerek enjekte et; çünkü testlerin yapmazsa, prod'daki retry'lar veri bozulmasını senden önce ortaya çıkarır. Dağıtık mimarilerde kalite mühendisliği; consumer lag, DLQ yönlendirmesi ve mesaj şemalarına görünürlük gerektirir.

Brokerların, partition'ların ve consumer offset'lerinin nasıl çalıştığını anlamıyorsan, olay güdümlü sistemler için dayanıklı bir doğrulama tasarlayamazsın. Peki ekibin asenkron iş akışlarını CI'da bugün nasıl test ediyor: hâlâ arayüz yoklama ve beklemelerle mi, yoksa koşum aracı doğrudan mesaj brokerlarına mı bağlanıyor?