React Auth E-postalarında Test Kararlılığı için Run ID Deseni
React tabanlı auth e-posta testlerinde flakiness'in gerçek nedeni zamanlama değil, UI ile posta kutusu arasındaki korelasyon eksikliği. TypeScript tabanlı bir run id deseni çözümü sunuyor.
React ile kurulan davet, magic-link veya doğrulama e-postası akışlarında testlerin kırılganlığı genellikle SMTP katmanından değil, arayüz durumu ile posta kutusuna düşen mesaj arasındaki kopukluktan kaynaklanır. Yazı, UI'ın isteğin başarılı olduğunu varsaymasıyla API'nin e-postayı kuyruğa almasının ayrı sorumluluklar olduğuna, test sürecinin ise sabit bir korelasyon anahtarı olmadan posta kutusunu yokladığına dikkat çekiyor. Sonuç, geçen bir toast testiyle birlikte yanlış e-posta içeriğinin gelmesi gibi tuhaf ama yaygın bir senaryo.
Önerilen çözüm, auth e-postasını bir ürün sözleşmesi gibi ele almak: kullanıcı eylemi başarılı olduğunda uygulama, isteği, kuyruğu ve posta kutusu kontrolünü birbirine bağlayan tek ve kararlı bir kimlik (run id, attempt id veya preview token) sunmalı. TypeScript ile tanımlanan basit bir AuthEmailExpectation tipi, bu beklenti nesnesinin hem UI eylemini hem API doğrulamalarını hem de posta kutusu aramasını beslemesini sağlıyor; böylece 'neredeyse eşleşen' kontroller ortadan kalkıyor.
Pratikte önerilen sıra şöyle: test formu göndermeden önce bir run id üretilir, bu kimlik istek gövdesi veya test-özel bir header ile taşınır, giden e-posta işine de aynı kimlikle kaydedilir ve posta kutusu araması sadece alıcı ile zaman aralığına değil bu kimliğe göre yapılır. Ayrıca inbox kontrolüne geçmeden önce React tarafında submit butonunun devre dışı kaldığı, başarı durumunun göründüğü ve dönen istek kimliğinin saklandığı doğrulanmalı. Bu ayrım, hata ayıklamayı da kolaylaştırıyor: UI doğruysa ama e-posta yanlışsa sorun şablon hattında, UI istek kimliğini hiç yakalamadıysa sorun daha erken bir noktada aranmalı.
Yazı ayrıca tam e-posta gövdesini snapshot'lamaktan kaçınmayı, yerine alıcı kimliği, konu niyeti, eylem URL'si ve birkaç metin parçası gibi kararlı unsurları doğrulamayı öneriyor. Run id eklenemeyen durumlarda alıcı, konu ve dar bir zaman aralığının birleşimi kabul edilebilir ama daha kırılgan bir alternatif olarak tanımlanıyor. Desen sadece magic-link'e özgü değil; davet, doğrulama, şifresiz giriş ve admin onay akışları gibi UI'ın e-postadan önce 'tamamlandı' dediği her senaryoda işe yarıyor.