Sürekli entegrasyonda mail yakalama: testler postayı nasıl okur?

Sürekli entegrasyonda mail yakalama, gönderilen postaları dışarıya çıkarmadan yerel bir dinleyiciye bırakıp testin doğrudan okumasıdır. Bu yaklaşım, testleri dış bir servisin çalışma saatlerine, kotasına ve erişim anahtarlarına bağımlı olmaktan kurtarır. Bu yazıda yerel yakalamanın nasıl çalıştığını, dış servise bağlanmaktan hangi noktalarda ayrıldığını ve testlerin postayla ilgili neyi kontrol etmesi gerektiğini bulacaksınız.

Sürekli entegrasyonda mail yakalama neden gerekli?

Bir kayıt akışını sınayan otomatik testin, gönderilen doğrulama postasını okuyabilmesi gerekir. Bu postayı gerçek bir adrese göndermek iki sorun doğurur: test, sizin kişisel kutunuzu kullanmak zorunda kalır ve sonuç, o kutunun o anki durumuna bağlı olur. Daha kötüsü, aynı testi yüzlerce kez çalıştırdığınızda kutunuz bu postayla dolar ve hangi postanın hangi çalıştırmaya ait olduğu belirsizleşir.

Yerel yakalama bu sorunu kaynağında çözer. Uygulamanın posta ayarı, test ortamında dışarıya değil yerel bir dinleyiciye işaret eder. Gönderilen posta hiç ağa çıkmaz, doğrudan yakalanır ve test onu okur. Böylece test, kendi ürettiği verinin sahibi olur; dışarıdaki hiçbir hesabın durumuna bağlı kalmaz.

Dış posta servisine bağlanmak neden kırılgan?

Dış bir posta servisiyle çalışan test, kontrolünüzde olmayan en az dört değişkene bağlıdır. Birincisi erişimdir: anahtar süresi dolar, kota aşılır ya da servis geçici olarak yanıt vermez. İkincisi gecikmedir: posta servisten size ulaşana kadar geçen süre değişkendir ve test bu süreyi tahmin etmek zorunda kalır. Üçüncüsü gürültüdür: gelen kutusunda sizin testinizden başka postalar da bulunur. Dördüncüsü gizliliktir: test postalarının içeriği, sizin denetiminizde olmayan bir sistemden geçer.

Bu değişkenlerin her biri testi kırabilir ve kırılma anı genellikle kodla ilgili değildir. Sonuç, ekibin testlere olan güvenini yitirmesidir: kırmızı yanan bir test, gerçek bir hatayı mı yoksa dış servisin o günkü huyunu mu gösterdiği belirsizleşir. Yerel yakalama, bu belirsizliği ortadan kaldırır.

Bir de maliyet tarafı vardır. Dış servisler genellikle aylık gönderim kotası ve ek kullanıcı ücretiyle çalışır; bu, testleri artırmayı pahalı hâle getirir. Test sayısı arttıkça fatura da artar ve ekip ister istemez test yazmayı azaltır. Yerel yakalama, test sayısını bir maliyet kalemi olmaktan çıkarır; bu yüzden test kapsamını genişletmek isteyen ekipler için ilk akla gelen çözümdür.

Yerel yakalama nasıl çalışır?

Kurulum birkaç adımdan oluşur ve hiçbiri uygulamanın iş mantığını değiştirmez:

• Test ortamının posta ayarı, dış sunucu yerine yerel bir dinleyici adresine yönlendirilir.
• Dinleyici, kendisine gelen mesajları bir dosyaya, bir veritabanına ya da belleğe yazar.
• Test, gönderimi tetikledikten sonra yakalanan mesajları bu kaynaktan okur ve aradığını bulur.
• Test bitince yakalanan mesajlar silinir; bir sonraki çalıştırma temiz bir kutudan başlar.

Bu akışın en büyük avantajı çevrimdışı çalışabilmesidir. Ağ bağlantısı olmayan bir ortamda, hatta geliştiricinin kendi dizüstü bilgisayarında testi çalıştırabilirsiniz. İkinci avantajı hızdır: posta, dışarı çıkıp geri dönmediği için testin bekleme süresi kısalır. Üçüncü avantajı ise gizliliktir; test verisi makinenin dışına çıkmaz.

Bu yaklaşımın bir yan faydası da şudur: test ortamı ile üretim arasındaki tek fark yapılandırmadır. Uygulama kodu, postayı gönderirken hangi sunucuya bağlandığını bilmek zorunda değildir; bu bilgi ortamdan gelir. Böyle kurulmuş bir sistemde üretime geçerken yapılan iş, testte kullanılan yerel hedefi gerçek posta sunucusuyla değiştirmektir. Aynı kodun iki ortamda bu kadar az farkla çalışması, testin üretimi temsil etme değerini artırır.

İki yaklaşım arasındaki fark ne?

Seçimi somutlaştırmak için iki yaklaşımı yan yana koymak yararlıdır:

Son satır, yerel yakalamanın tek zayıf noktasını gösterir: gerçek teslim yolunu sınamaz. Bu yüzden bazı ekipler hem yerel yakalamayı hem de küçük bir dış doğrulama adımını birlikte kullanır; asıl test yükü yerelde kalır. Dış doğrulama, teslim zincirinin bozulmadığını gösteren seyrek bir kontrol olarak yeterlidir; her çalıştırmada dışarı çıkmak, kaçınmaya çalıştığınız kırılganlığı geri getirir.

Testler neyi kontrol etmeli?

Yakalanan mesaj yalnızca “geldi mi” sorusuna cevap vermemelidir. Testin asıl değeri, mesajın içeriğini denetlemesidir. Alıcı adresi doğru mu, konu satırı beklenen metni taşıyor mu, gövdedeki bağlantı testin beklediği hedefe gidiyor mu, mesaj yalnızca o senaryonun verisini mi içeriyor? Bu soruların her biri ayrı bir doğrulama satırıdır.

İkinci kontrol grubu, akışın kendisine aittir. Aynı işlem iki kez tetiklendiğinde iki posta mı gidiyor, yoksa tek posta mı? Adres değiştirildiğinde eski adrese posta gitmeye devam ediyor mu? Bu davranışlar yalnızca postayı okuyarak görülebilir. Üçüncü grup ise olumsuz durumlardır: posta gönderimi başarısız olduğunda uygulama ne yapıyor, kullanıcıya anlaşılır bir mesaj gösteriyor mu, yoksa sessizce mi kalıyor? Bu yol, mutlu yoldan daha az denenir ama üretimde en çok sorun çıkaran yoldur.

Geliştiriciler için: port, paralellik ve hata ayıklama

Yerel bir dinleyici kurarken ilk dikkat edilecek nokta, çakışmadır. Aynı makinede paralel çalışan testler aynı dinleme noktasını paylaşırsa birinin postasını diğeri okur. Bunun iki çözümü vardır: her test sürecine kendi dinleme noktasını vermek ya da tek dinleyici kullanıp postaları alıcı adresine göre ayırmak. Hangisini seçerseniz seçin, her senaryonun kendi adresini üretmesi şarttır.

İkinci nokta, bekleme biçimidir. Test, posta geldi diye sabit bir süre beklememeli; yakalanan mesajlar arasında aradığını bulana kadar belli aralıklarla denetlemeli ve bir üst sınırda başarısız olmalıdır. Bu sınır, yavaş bir ortamda yalancı hata üretmeyecek kadar geniş, gerçek bir arızada testi asılı bırakmayacak kadar dar olmalıdır.

Üçüncü nokta, hata anında ne olduğunun görülebilmesidir. Bir doğrulama başarısız olduğunda test, yakalanan ham mesajı bir yere bırakmalıdır; aksi hâlde “konu satırı eşleşmedi” mesajı, sorunun şablonda mı yoksa beklentide mi olduğunu söylemez. Yakalanan postaları çalıştırma sonunda silmek de gereklidir; aksi hâlde bir sonraki çalıştırma eski postayı okuyabilir. Bu konuda OTP gibi kısa kodların nasıl okunacağını uçtan uca testlerde OTP yazısında, hazırlık ortamında toplu yakalamayı ise her şeyi yakalayan posta kutusu yazısında bulabilirsiniz.

Sonraki adımlar

İlk adım, test ortamının posta ayarını dış servisten yerel bir dinleyiciye çevirmektir; uygulama kodu bu değişiklikten etkilenmez, yalnızca yapılandırma değişir. İkinci adım, her senaryoya kendi adresini verip yakalanan mesajları çalıştırma sonunda temizlemektir. Üçüncü adım, yakalanan içeriğin ne kadar süre saklanacağını ve kimlerin erişebileceğini belirlemektir; test kutusunda biriken içerik de sonuçta bir veri deposudur. Yaklaşımı küçük bir denemeyle görmek isterseniz geçici e-posta aracında bir adres üretip kayıt akışını uçtan uca izleyebilirsiniz; test verisi üretme alışkanlığınızı gözden geçirmek için çevrimiçi üreticiler ve kütüphaneler yazısı da işinize yarar.

Bu ortamda üretilen adreslerin tek amacı testtir; gerçek yazışma veya kimlik için uygun değildir.