OTP testi, bir uygulamanın gönderdiği tek kullanımlık kodu uçtan uca akışta otomatik olarak okuyup forma yazmaktır. Kulağa basit gelir: postayı bul, içindeki sayıyı al, gir. Gerçekte ise testler en çok burada kırılır; çünkü posta gecikir, eski postalar kutuda kalır ya da hizmet yeniden gönderme isteğini sınırlar. Bu yazıda bu kırılganlıkların nedenlerini ve kodun güvenilir biçimde nasıl okunacağını bulacaksınız.
OTP testi neden kırılgan olur?
Kırılganlığın kaynağı, testin denetimi dışındaki zamanlamadır. Kod, uygulamanın içinde bir anda üretilir; ama posta olarak kullanıcıya ulaşması bir teslim sürecinden geçer. Bu süreçte gecikme olabilir, aynı posta iki kez gelebilir ya da posta hiç gelmeyebilir. Test ise kodun belli bir anda elinde olmasını bekler. Bu beklenti ile gerçek teslim davranışı arasındaki fark, kırılganlığın tamamını açıklar.
İkinci kaynak, kodun kendisidir. Tek kullanımlık kodların kısa bir geçerlilik süresi vardır ve yeniden gönderme istekleri sınırlıdır. Bu iki kural kullanıcıyı korumak için tasarlanmıştır; yani bir arıza değil, bilinçli bir davranıştır. Test, bu kuralları ihlal ederek değil, onlara uyarak yazılmalıdır. Aksi hâlde test, üretimde hiç karşılaşılmayan bir hızda çalışır ve gerçek riskleri görünmez kılar.
Kod, test posta kutusundan nasıl alınır?
Akış birkaç adıma ayrılır ve her adımın kendi hata payı vardır:
- Tetikleme: Test, kayıt ya da giriş ekranını doldurup kod isteğini başlatır.
- Bekleme: Test, gelen kutusunu belli aralıklarla denetler; sabit bir süre uyumaz.
- Seçim: Kutuda birden fazla posta varsa test, aradığı postayı ayırt edecek bir ölçüt kullanır.
- Çıkarma: Postanın içinden kod bulunur; konu satırı, gövde metni ve biçim birlikte değerlendirilir.
- Geri yazma: Bulunan kod forma girilir ve akışın devam ettiği doğrulanır.
- Temizlik: Kullanılan posta işaretlenir ya da silinir; sonraki adımda tekrar okunmaz.
Bu adımların her biri ayrı bir test iddiasına dönüşebilir. Örneğin “kod bulundu” ile “kod forma girildiğinde akış ilerledi” aynı şey değildir; ikincisi olmadan test, yalnızca postanın geldiğini gösterir.
Doğru posta nasıl seçilir?
Kutuda tek posta varsa seçim sorunu yoktur; ama paralel çalışan testler ya da aynı adrese gönderilmiş birden fazla posta olduğunda seçim kritik hâle gelir. En güvenilir ölçüt, testin kendi ürettiği ayırt edici bilgidir: alıcı adresinin kendisi. Her senaryoya ayrı bir adres verildiğinde, hangi postanın o senaryoya ait olduğu tartışmasız olur.
Adres ayrımı yapılamıyorsa ikinci ölçüt, gönderen ve konu satırıdır. Test, beklediği göndereni ve konu desenini tanımlamalı, bunlarla eşleşmeyen postaları yok saymalıdır. Üçüncü ölçüt, zamandır: testin başlamasından sonra gelen postalar dikkate alınır. Bu üçünü birlikte kullanmak, yanlış postayı okuma olasılığını en aza indirir.
Eski postalar neden karıştırılır?
Bir test çalıştırması sona erdiğinde gelen kutusunda postalar kalabilir. Bir sonraki çalıştırma aynı kutuyu kullanıyorsa, kod arayan mantık önce eski postayı bulur ve testi yanlış yönlendirir. Bu, en sık yapılan hatadır ve belirtisi sinsidir: test bazen geçer, bazen kalır; hata mesajı ise koddan değil, akışın geri kalanından gelir.
Çözüm, kutuyu çalıştırma öncesi boşaltmak ya da bu çalıştırmaya ait postaları ayırt edebilmektir. İkinci yol daha dayanıklıdır; çünkü test paralel çalıştığında kutuyu boşaltmak diğer testin postasını da silebilir. Her senaryoya kendi adresini vermek, bu iki çözümü birleştirir: kutu paylaşılmaz ve eski posta başka bir adrese aittir. Gelen kutusunu okuma biçiminin ayrıntıları için sürekli entegrasyonda mail yakalama yazısına bakabilirsiniz.
Karışıklığın bir başka biçimi, aynı akışın iki kez tetiklenmesidir. Kullanıcı iki kez kod istediğinde iki posta gelir ve iki kod da bir süre geçerli olabilir. Testin hangisini okuduğu sonucu değiştirmemelidir; ancak gerçekleşen davranış, ürünün ilk kodu geçersiz kılıp kılmadığını gösterir. Bu ayrımı test etmek, hem akışın tutarlılığını hem de kullanıcıya gösterilen mesajların doğruluğunu ortaya çıkarır. Eski bir kodla giriş denendiğinde ne olduğunu da sınamak, güvenlik açısından değerli bir kontroldür.
Yeniden gönderme sınırına takılırsanız ne olur?
Bir kod gelmediğinde ilk tepki yeniden göndermeyi istemektir. Ancak bu istek sınırlıdır ve kısa sürede tekrarlanırsa hizmet isteği reddeder. Test, bu durumda iki yanlış yola sapabilir: sınırı aşmak için beklemeye çalışır ya da ürün ayarını değiştirip sınırı kapatır. İkincisi en tehlikeli olandır; çünkü doğrulama akışının en önemli koruma mekanizması testte devre dışı kalır ve üretimde ortaya çıkacak davranış hiç sınanmaz.
Doğru yaklaşım, sınırı testin beklediği bir davranış olarak ele almaktır. Yeniden gönderme isteği reddedildiğinde kullanıcıya ne gösteriliyor, ne kadar beklemesi gerektiği anlatılıyor mu, ilk kod hâlâ geçerli mi? Bu sorular test edilmeye değerdir ve ürünün gerçek davranışını yansıtır. Kod geciktiğinde yapılacak şey, sabit süre beklemek yerine gelen kutusunu yoklamak ve belli bir üst sınırda başarısız olmaktır.
Geliştiriciler için: ayrıştırma, üst sınır ve insan desteği
Kodu postadan çıkaran mantık, mümkün olduğunca dar bir varsayımla yazılmalıdır. Gövdedeki ilk uzun sayıyı almak gibi bir kural, sayfa numarası, sipariş numarası veya yıl gibi değerleri kod sanabilir. Bunun yerine kodun biçimini tanımlayan bir desen ve kodun bulunduğu bağlamı işaretleyen bir metin birlikte aranmalıdır. Konu satırını da eşleştirmeye katmak, yanlış postayı okuma riskini azaltır.
İkinci nokta, üst sınırdır. Yoklama döngüsünün bir sonu olmalı ve bu son, gerçek bir arızada testi asılı bırakmayacak kadar kısa, yavaş ortamda yalancı hata üretmeyecek kadar uzun seçilmelidir. Üst sınıra ulaşıldığında hata mesajı, neyin beklendiğini ve neyin bulunduğunu anlatmalıdır; yalnızca zaman aşımı demek, sorunu inceleyen kişiyi çaresiz bırakır.
Üçüncü nokta, insan desteğinin nerede gerektiğidir. Her senaryo otomatikleştirilemez. Gerçek bir cihazda gelen postayı açmak, kodu elle girmek ya da sınırın davranışını gözle görmek gereken durumlar vardır. Bu durumları otomasyona zorlamak, testi kırılgan hâle getirir. Bunun yerine, otomatik testler ile elle yapılan kontrollerin sınırını açıkça çizmek ve hangi senaryonun hangi tarafa ait olduğunu belgelemek gerekir. Kodun geçerlilik süresi ve tekrar gönderim davranışı ürünün kurallarıdır; testin görevi bu kuralları doğrulamaktır, onları esnetmek değil.
Son bir ayrıntı, kodun okunma anıyla ilgilidir. Test kodu bulduğunda onu hemen kullanmak yerine, kodun hangi isteğe ait olduğunu da kaydetmelidir. Böylece iki kod arasında karışma olduğunda hangi kodun hangi denemeye karşılık geldiği görülebilir. Bu kayıt, test başarısız olduğunda incelemeyi dakikalar içinde sonuçlandırır.
Sonraki adımlar
İlk adım, her senaryoya kendi adresini vermek ve yoklamayı sabit beklemelerden kurtarmaktır; bu iki değişiklik, OTP testlerindeki kırılmaların çoğunu ortadan kaldırır. İkinci adım, kodun bulunamadığı durumda testin ne yapacağını netleştirmektir: ne kadar bekleyecek, hangi bilgiyi kaydedecek, hangi durumda başarısız sayacak? Yaklaşımı kendi ortamınızda denemek için geçici e-posta aracında bir adres üretip gelen kodu izleyebilirsiniz; doğrulama akışının tamamını gözden geçirmek için mail doğrulama akışı testi yazısı eşlik eder.
Doğrulama kodlarını sınamak için üretilen adresler geçicidir; gerçek bir kimlik ya da sürekli bir hesap adresi değildir.