Test Email Change Flows Without Missed Links
Bir hesap e-postasını değiştirmek küçük bir işlem gibi görünür. Ancak QA ekipleri için yaygın bir tuzaktır. Bir test uzmanı bir adresi günceller, başka biri ise e-postayı ilk açan kişi olur. Sonuçta ekip, React sayfasının mı bozuk olduğu yoksa bağlantının yanlış kullanıcıya mı ait olduğu konusunda tartışmaya başlar.
Bu kafa karışıklığı, gelen kutusunu özelliğin bir parçası olarak değil de paylaşılan bir araç olarak ele aldığınızda ortaya çıkar.
E-posta değiştirme süreçleri hassastır. Aktif hesapları değiştirirler. Kimliği doğrulanmış kullanıcılar ve beklemede olan durumlarla (pending states) uğraşırsınız.
Yaygın sorunlar şunları içerir:
- Mesajlar, net bir sahibi olmayan paylaşılan bir gelen kutusuna gelir.
- Bağlantı çalışır ancak UI eski verileri gösterir.
- Backend güncellenir ancak frontend önbelleği (cache) güncel kalmaz.
- Test uzmanları, diğer test uzmanları için ayrılmış bağlantılara tıklar.
Bunu düzeltmek için her bir test çalışması için geçici (burner) bir e-posta kullanın. Tek bir staging takma adı (alias) kullanmayın.
Şu sırayı izleyin:
- Uygulama üzerinden bir test kullanıcısı oluşturun.
- React ayarlarından bir e-posta değişikliği talep edin.
- E-postayı gerçek backend üzerinden gönderin.
- Mesajı tek kullanımlık bir gelen kutusuna yönlendirin.
- Bağlantıyı açın ve ayarlar ekranının yeni adresi gösterdiğini doğrulayın.
İzolasyon, sahipliği net tutar. Hangi gelen kutusunu kullandığınızı hatırlamak için Slack'te karmaşık notlara ihtiyacınız kalmaz.
React uygulamaları için bir kural: Her zaman yeni bir veri okumasından sonra ekranı kontrol edin. İyimser istemci durumuna (optimistic client state) güvenmeyin. Mutation başarılı dönebilir ancak sayfa yenilemesi eski değeri geri getirebilir. Bu, insanların itiraf ettiğinden daha sık gerçekleşir.
Uçtan uca (end-to-end) testiniz şunları doğrulamalıdır:
- E-posta, yeni beklemedeki (pending) adrese gider.
- Bağlantı doğru host'a işaret eder.
- Bağlantı hesap kaydını günceller.
- Veri yeniden çekildikten (refetch) sonra eski adres kaybolur.
- Bağlantının yeniden kullanılması güvenli bir şekilde başarısız olur.
Frontend doğrulamaları (assertions) en önemli kısımdır. Kullanıcı yanlış adresi görüyorsa, backend günlüğünün "başarılı" demesi anlamsızdır. Eğer önbelleğiniz (cache) veya store'unuz güncel değilse, özellik bozuk demektir.
İzlenebilirlik de yardımcı olur. Günlüklerinizde ve e-posta meta verilerinde bir korelasyon kimliği (correlation ID) kullanın. Bu, isteği teslimat ve onay ile birbirine bağlar.
Dikkate alınması gereken ödünleşimler (tradeoffs):
- Gelen kutusunu sorgulamak (polling), mock'lardan daha yavaştır.
- Tek kullanımlık adresler yalnızca üretim dışı (non-production) verileri barındırmalıdır.
- Önizleme ortamlarının temizleme kurallarına ihtiyacı vardır.
Bunu atlamayın. E-posta akışları, sistemler arasındaki boşluklarda bozulur. Mock'ların en zayıf olduğu yer de burasıdır.