Test adres verisi, bir yazılımın adresle ilgili bütün davranışını tekrar tekrar aynı koşullarda sınamak için hazırlanan sabit kayıtlar kümesidir. Bu yazıda bu kayıtların nasıl düzenleneceğini, neden gerçek müşteri adreslerinin test ortamına taşınmaması gerektiğini ve hangi sınır örneklerinin mutlaka bulunması gerektiğini bulacaksınız.
Test adresleri neden sabit bir dosyada tutulur?
Rastgele üretilen bir adresle yapılan test, yalnızca o çalıştırmada geçerlidir. Test başarısız olduğunda elinizde tekrar üretilebilir bir örnek yoktur; aynı hatayı ikinci kez görmek için aynı rastgele değeri yakalamanız gerekir. Bu yüzden adres verisi sabit bir dosyada tutulur ve her çalıştırmada aynı değerler kullanılır.
Sabit verinin ikinci faydası, karşılaştırma yapmayı kolaylaştırmasıdır. Bir doğrulama kuralını değiştirdiğinizde, hangi kayıtların artık geçmediğini net biçimde görürsünüz. Bu, rastgele veriyle mümkün olmayan bir ayrımdır; çünkü rastgele veride her çalıştırmada farklı kayıtlar geçer ya da geçmez.
Üçüncü fayda, ekibin aynı dili konuşmasıdır. Herkes aynı örnek kayıtları gördüğünde, hata bildirimleri kısa ve anlaşılır olur. Kimse “şu uzun adresli kayıt” gibi belirsiz bir tarif yapmak zorunda kalmaz.
Kayıtlar nasıl adlandırılır ve gruplanır?
Kayıtları adlandırırken amacı değil, senaryoyu yazın. Amacı yazmak kısa sürede belirsizliğe yol açar. Buna karşılık ülke ve durum bilgisi içeren adlar, dosyayı okunur kılar. Aşağıdaki tablo, örnek bir gruplamayı gösterir:
| Grup | Ne sınar |
|---|---|
| Sade adres | En kısa mutlu yol: tek satır sokak, şehir, bölüm, posta kodu |
| Birimli adres | Daire veya kat bilgisi ayrı satırda |
| Uzun satır | Sokak adının alan sınırına dayandığı durum |
| Kodu olmayan ülke | Posta kodu alanının boş kalması gereken ülke |
| Latin dışı yazı | Yerel alfabeyle yazılmış adres |
| Tutarsız kayıt | Bölüm ile posta kodunun uyuşmadığı kayıt |
Grupları dosya düzenine de yansıtmak gerekir. Ülkeye göre ayrı dosyalar, o ülkeye özgü bir kural değiştiğinde yalnızca ilgili dosyayı güncellemenizi sağlar. Senaryoya göre gruplamak ise belirli bir davranışı sınayan testlerin hangi veriyi kullandığını netleştirir.
Aynı kaydı birden fazla gruba koymaktan kaçının. Bir kayıt yalnızca bir yerde tanımlanmalı ve diğer dosyalar ona referans vermelidir. Böylece bir değer değiştiğinde tek bir yer güncellenir ve testlerin bir kısmının eski veriyle çalışması önlenir.
Gerçek müşteri adresleri neden kullanılmamalı?
Gerçek bir adres, arkasında bir kişi bulunan kişisel bir veridir. Bu veriyi test ortamına kopyalamak, aynı verinin iki yerde durması anlamına gelir. Test ortamları genellikle üretim ortamı kadar sıkı korunmaz; erişim yetkileri daha geniştir ve yedekler daha uzun süre saklanır. Bu da veri için gereksiz bir yayılma riski yaratır.
İkinci sorun, verinin sürekli değişmesidir. Gerçek kayıtlar güncellenir, silinir ve yeni kayıtlar eklenir. Test ortamı üretimden kopyalandığında testlerin beklediği değerler değişir ve sonuçlar tutarsız hale gelir. Kurgusal veri ise yalnızca siz değiştirdiğinizde değişir.
Üçüncü sorun, paylaşımdır. Bir hata kaydını dışarıdan bir ekip ile paylaşmanız gerektiğinde, gerçek adres içeren bir dosyayı olduğu gibi paylaşamazsınız. Kurgusal veri, paylaşım için üretilmiştir; bu yüzden hiçbir maskeleme işine gerek kalmaz.
Adres verisi ne kadar çeşitlendirilmeli?
Çeşitlilik, kapsama ile orantılı olmalıdır. Sisteminiz yalnızca bir ülkeyi destekliyorsa, on ülkeye ait kayıt saklamanın faydası sınırlıdır. Buna karşılık birden fazla ülkeyi destekliyorsanız, bu ülkeler arasından biçim olarak birbirinden ayrılan en az üç tanesini seçmek gerekir: saf rakamlı posta kodu kullanan bir ülke, harf karışık kod kullanan bir ülke ve kodu hiç olmayan bir ülke.
Sınır değerleri de çeşitliliğin parçasıdır. Sokak satırının izin verilen en uzun hali, boş ikinci satır, tek karakterlik şehir adı ve rakam içeren sokak adı; bu dördü, doğrulama kodunuzun uçlarını sınar. Bu örnekler, günlük kullanımda nadiren görülür ama sistemin kırıldığı yer genellikle tam olarak buralardır.
Kurgusal verinin uzunluğu da önemlidir. Çok az kayıt, kapsamı daraltır; çok fazla kayıt ise bakımı zorlaştırır ve hangi kaydın ne için durduğu unutulur. Onlarca değil, onlarca senaryoyu kapsayan küçük ve anlaşılır bir küme çoğu proje için yeterlidir. Sınır örneklerini seçerken alanın gerçekte nasıl davrandığını bilmek işinizi kolaylaştırır; ABD adres yapısı yazısındaki ayrımlar bu seçimi somutlaştırır.
Kurgusal adres gerçek bir adrese benziyorsa ne olur?
Üretilen bir adres, gerçek bir adrese fazlasıyla benzeyebilir. Bu, biçim açısından istenen bir şeydir; çünkü amaç gerçek veriyle aynı yapıyı sınamaktır. Ama aynı benzerlik, verinin yanlış kullanılması riskini de doğurur. Kurgusal bir kayıt, gözle gerçek olandan ayırt edilemez.
Bunun önüne geçmenin yolu, kaydı işaretlemektir. Kurgusal olduğunu belirten bir alan, bir etiket ya da tutarlı bir ön ek kullanmak, verinin test ortamı dışına çıktığında yanlış anlaşılmasını engeller. Bu işaret, yalnızca teknik bir önlem değil, aynı zamanda ekibin ortak kuralıdır.
Bir diğer önlem, üretilen kaydın hiçbir zaman gerçek bir teslim noktasına denk gelmemesidir. Test için üretilen adresler yalnızca yazılım testi, form demosu ve gizlilik koruması içindir; gerçek gönderi, ikamet kanıtı ya da doğrulama atlatma amacıyla kullanılamaz.
Geliştiriciler için: sabit dosyaların yapısı
Sabit veriyi kodun içine gömmek yerine ayrı bir veri dosyasında tutun. Böylece aynı veriyi farklı test araçları kullanabilir ve dosya bağımsız olarak gözden geçirilebilir. Dosyanın biçimini de sabitleyin; aynı alan adları her kayıtta aynı anlamı taşımalıdır.
Her kaydın yanına neyi sınadığını yazın. Kısa bir açıklama alanı, aylar sonra dosyaya dönen kişinin neden o kaydın orada durduğunu anlamasını sağlar. Bu, testin kendisi kadar değerlidir; çünkü kapsamı olmayan bir kayıt, bakım sırasında ilk silinen kayıt olur.
Kurgusal kayıtları üretirken alanları birbirinden bağımsız doldurmayın. Şehir, bölüm ve posta kodu aynı bölgeye ait olmalıdır; aksi halde tutarlılık kontrolü sürekli uyarı üretir ve gerçek hatalar bu gürültüde kaybolur. Tutarsız bir kayıt gerekiyorsa, bunu bilinçli olarak işaretleyin ve ayrı bir grupta tutun.
Son olarak, sabit veriyi sürümle birlikte yönetin. Bir kaydın değerini değiştirmek, beklenen sonuçları da değiştirir; bu yüzden değişikliği tek bir yerde ve açık bir gerekçeyle yapmak, testlerin sessizce gevşemesini önler.
Sonraki adımlar
Sabit veri kümenizi kurarken önce hangi ülkeleri desteklediğinizi listeleyin, sonra her ülkeden bir mutlu yol ve bir sınır örneği seçin. Yeni kayıt üretmeniz gerektiğinde adres üretici sayfasından ülke seçip alanları kopyalayabilir, kurgusal verinin sınırlarını ise sanal adres nedir yazısında ayrıntılı olarak görebilirsiniz.