E-posta testleriniz dizüstü bilgisayarınızda kusursuz çalışıyor ancak CI'a ulaştığı anda çöküyorsa, yalnız değilsiniz. Alışılagelmiş tepki, test kodunun arasına sleep çağrıları serpiştirmek veya derleme (build) geçene kadar yeniden deneme (retry) sayısını artırmaktır. Bu, gürültüyü bir günlüğüne dindirebilir ancak hatayı düzeltmez; sadece gizler.

Asıl sorun, testinizin hangi e-postayı açacağını nasıl belirlediğidir.

Paylaşılan Gelen Kutusu Sorunu

Yerel makinenizde testleri teker teker çalıştırırsınız. Bir e-posta gelir. Onu alırsınız. Bu kadar basit.

CI tamamen farklı bir ortamdır. Tek bir pull request; dört, sekiz veya on altı paralel iş (job) tetikleyebilir. Eğer hepsi ortak bir test gelen kutusunu paylaşıyorsa —ister bir Mailosaur sunucusu, ister bir Mailtrap gelen kutusu, ister staging alan adındaki gerçek bir hesap olsun— hepsi aynı anda aynı kovaya (bucket) yazıyor demektir. A İşlemi bir şifre sıfırlama gönderir. B İşlemi bir davetiye gönderir. C İşlemi başarısız olan bir karşılama akışını yeniden dener. Bu sırada arka plan çalışanları (background workers) ve teslimat kuyrukları, kontrol edemeyeceğiniz bir dalgalanmaya (jitter) neden olur.

Her bir işlem o paylaşılan

Pratik olarak, yardımcınız Subject:"Welcome to AppName" sort:-received yerine Subject:"Welcome to AppName" AND Body:"a4f9c2d1" ifadesini aramalıdır. Birçok e-posta test servisi, gövde içeriği filtrelerini kabul eden arama API'leri sunar. Bunları kullanın. Daha basit bir sağlayıcı ile çalışıyorsanız, istemci tarafı filtrelemeyi her testte tutarlı bir şekilde ekleyebilmek için sorgulama (polling) mantığınızı tek bir yerde tutun.

Sistemi Dürüst Tutmak İçin Üç Kural

Bir çalışma belirteci (run token) seçimi sabitler, ancak yine de nasıl sorgulama yaptığınız ve işler ters gittiğinde ne yaptığınız konusunda disipline ihtiyacınız vardır.

Hata durumunda gelen kutusu durumunu günlüğe kaydedin. Bir test başarısız olduğunda; gelen kutusu tanımlayıcısını, sorguladığınız konu satırını, tam zaman damgası aralığını ve kriterlerinize uyan mesaj sayısını çıktı olarak verin. Bu, belirsiz bir "e-posta bulunamadı" hatasını somut bir hikayeye dönüştürür. Eğer 7823 numaralı iş, üç saniye sonra geldiği için 7821 numaralı işten gelen bir yeniden deneme mesajını aldıysa, günlükleriniz bunu açıkça göstermelidir. Bu bağlam olmadan, zamanlamayı suçlayacak ve yeni bir sleep ekleyeceksiniz.

Tüm e-posta sorgulama işlemlerini tek bir yardımcı dosyada tutun. setTimeout ve cy.task çağrılarını yirmi farklı test dosyasına dağıtmayın. Mesajları bekleyen, API çağrısını yeniden deneyen ve backoff uygulayan mantığı merkezileştirin. Eğer her test aynı yardımcıyı kullanırsa, filtreleme kurallarınız tutarlı kalır ve arama mantığını iyileştirdiğinizde her test bundan faydalanır. Bu ayrıca belirteç kontrolünü zorunlu kılmayı da kolaylaştırır; eğer yardımcı bir belirteç argümanı gerektiriyorsa, hiç kimse yanlışlıkla "en son mesaj" dayanağına sığınamaz.

Yeniden denemelerinizi takip edin. CI ortamlarında testlerin yeniden denenmesi yaygındır, ancak her yeniden deneme gelen kutusunda başka bir e-posta oluşturur. Eğer testiniz üçüncü denemede geçerse, kutlama yapıp yolunuza devam edebilirsiniz. Kaçırdığınız şey, birinci ve ikinci denemelerin; fazladan mesajların maskelediği gerçek bir hatayı —bir yarış durumu (race condition), mükerrer gönderim veya eksik bir indeks— ortaya çıkarmış olmasıdır. Eğer yeniden denemeleri kullanmak zorundaysanız, bir hatadan sonra gelen kutusunun beklenmedik mükerrer kayıtlar içerip içermediğini kontrol edin. Daha da iyisi, sağlayıcınız dinamik gelen kutularını destekliyorsa, gelen kutusunu temizlemeyi veya her iş için benzersiz bir adres kullanmayı düşünün. Yeniden denemeler, güvenilmez seçim mantığını absorbe etme stratejisine dönüşmemelidir.

Asıl Çıkarım

Bir gelen kutusunu tarihe göre sıralamak ve en üstteki sonucu almak test yapmak değildir. Bu, kodla süslenmiş bir tahminden ibarettir. Bir çalışma belirteci neredeyse hiçbir maliyete sahip değildir —bir dize değişkeni, bir ekstra filtre parametresi, belki küçük bir şablon değişikliği— ve testinize deterministik bir kimlik kazandırır. Önünüzdeki mesajın, şu anda yürüttüğünüz çalışmaya ait olduğunu kanıtlar.

sleep eklemeyi ve ağın düzgün çalışmasını ummayı bırakın. Bir belirteç oluşturun, onu e-postaya koyun ve doğrudan onu arayın. CI süreçleriniz daha hızlı olacak, günlükleriniz okunabilir hale gelecek ve e-posta paketinin size söylediklerine nihayet güvenebileceksiniz.