Faker.js ve çevrimiçi veri üreticileri: hangisini ne zaman kullanmalı

Sahte bir kayıt elde etmenin üç yolu var ve bunlar birbirinin yerini tutmaz. Bir kütüphane sizin sürecinizin içinde çalışır ve size değerler verir. Barındırılan bir üretici, ağ çağrısı üzerinden eksiksiz kayıtlar döndürür. Çevrimiçi bir araç ise bir insana düğmeli bir sayfa sunar. Yanlış seçim size ya tekrarlanabilirliği ya da zamanı kaybettirir ve bu maliyet genellikle aylar sonra, kimsenin güvenmediği bir test paketinde ortaya çıkar.

Üç yol ve neden birbirinin yerini tutmaz

Üçünün de çözdüğü sorun aynı görünür: gerçek bir kişiye ait olmayan bir kayıt üretmek. Ayrıldıkları yer, kaydın nerede üretildiği ve o kaydın ne vaat ettiğidir. Kütüphane, sürecinizin içinde alan alan değer üretir. Barındırılan üretici, bir ülke için bütün bir kaydı ağ üzerinden döndürür. Çevrimiçi araç, aynı işi bir insanın eliyle tek seferde yapmasını sağlar.

Bu üçü arasındaki asıl fark hız ya da kolaylık değil, tutarlılığın nerede kurulduğudur. Alan bazlı üretimde şehir, posta kodu ve telefon numarası ayrı havuzlardan gelir ve aralarındaki bağı yazmak size düşer. Kayıt bazlı üretimde bağ, veri kümesinin kendisindedir. Bir fixture’ın hangi vaadi taşıdığını bilmek, doğru aracı seçmekten önce gelir.

Üç yolun kısa karşılaştırması şöyledir.

Kütüphane: Faker ve benzerleri

Veri sahteleme kütüphanesi, projenizde istek üzerine değer üreten bir bağımlılıktır. JavaScript ekosisteminde akla ilk gelen örnek Faker’dır ve çoğu ekip önce ona uzanır.

Güçlü yanları gerçektir. Çevrimdışı çalışır, dolayısıyla birim testleri ağa ihtiyaç duymaz. Bir test döngüsünün içinde üretim yapacak kadar hızlıdır. Uzun bir yerel ayar listesi boyunca ad, telefon numarası, adres ve şirket adı için tipli üreticiler sunar; fabrikalara ve fixture’lara kolayca oturur ve geçerli bir alan nesnesi birkaç satırda kurulur. Yerel ayar bazlı ad üretiminin ayrıntıları yerel ayara göre ad verisi sayfasında anlatılıyor.

Sınırları da aynı ölçüde gerçektir. Bir kütüphane alan üretir, dolayısıyla kayıt genelinde tutarlılık sizin sorununuz hâline gelir: şehir, posta kodu ve telefon numarası, aralarında bağ kuran kodu siz yazmadıkça ayrı havuzlardan gelir. Yerel ayar kapsamının derinliği dengesizdir; adlar genellikle iyi kapsanır, sokak düzeyindeki adres yapısı çok daha az kapsanır.

Tekrarlanabilirlik de yalnızca tohuma bağlı değildir. Tohumlanmış çıktı, kütüphanenin sabit bir sürümü için kararlıdır; ancak veri havuzları ve iç sıralama ana sürümler arasında değişir, yani bir yükseltme tohum aynı kalsa bile her fixture’ı yeniden karıştırabilir. Testleriniz beklenen çıktıyı sabit kodluyorsa, rutin bir bağımlılık güncellemesi bir fixture göçüne dönüşür.

Fabrikalar bu bağı görünür kılar. Bir fabrika, üreticiyi sabit bir sırayla çağırır; böylece en azından nesnenin kendi şekli tutarlı olur. Yapamadığı şey, çıktısını sahip olmadığı bir kurala karşı denetlemektir: makul görünen bir sokak ile beş haneli bir posta kodunu, ikisinin aynı yere ait olup olmadığını bilmeden üretebilir. İç tutarlılık ile dış doğruluk farklı özelliklerdir ve bir kütüphane yalnızca ilkini sunar.

Barındırılan üretici neyi farklı yapar?

Barındırılan üretici, veri modelini servise taşır. Alan alan değer birleştirmek yerine bir ülke için kayıt istersiniz ve eksiksiz bir kayıt alırsınız: kişi, adres, posta kodu, telefon ve ülke bir algoritma yayımlıyorsa onunla tutarlı bir kimlik numarası.

Avantaj veri modelidir. Ülke veri kümesi üzerine kurulu bir üretici, idari bölümü, şehri ve posta kodunu bir arada tutabilir; bu, alan bazlı bir kütüphanenin yardımcı olamayacağı hata sınıfıdır. Ülke dizini uydurulmuş dizelerden değil referans verisinden inşa edilir; idari bölüm, şehir ve posta kodu tek bir kayıttan okunur, bu yüzden birbirleriyle çelişemezler. Adres aracı bu modeli kayıt bazında gösterir.

Kontrol basamakları, var olduğu yerlerde ülke bazlı uygulamalardan gelir: Brezilya’nın CPF’si, İspanya’nın DNI’sı, Türkiye’nin T.C. Kimlik numarası, Meksika’nın CURP’si ve Şili’nin RUT’u bunlar arasındadır. Bir ülke algoritma yayımlamıyorsa, doğrulama aracı numaranın geçerli olduğunu ima etmek yerine bunu açıkça söyler. Bu ayrım önemlidir, çünkü doğru uzunlukta bir dize ile kontrol basamağı hesaplanmış bir numara aynı şey değildir ve bir KYC akışı ikisini farklı değerlendirir.

Maliyetler operasyoneldir. Bir testteki ağ çağrısı başlı başına bir arıza biçimidir; dışa çıkışı olmayan bir CI çalıştırıcısı servise hiç ulaşamaz. Ayrıca servis tarafında bir şey değiştiğinde ortaya çıkan test arızasını sizin tarafınızdan düzeltmenin bir yolu yoktur.

İşte bu yüzden belirleyici bir anahtar, zengin bir veri modelinden daha önemlidir. Aynı anahtar artı aynı ülke her zaman aynı kaydı döndürüyorsa, bir test fixture’ı kaydetmek yerine anahtarla sabitleyebilir; elde ettiğiniz kararlılık, alttaki havuzların hiç değişmeyeceği vaadi değil, kararlı bir eşlemedir. İkisi de işe yarar; ama yalnızca ilki üzerine iddia yazabileceğiniz bir sözleşmedir.

Bir sınır yine kalır: ülke farkındalığı olan bir üretici, modellediği alanlar arasındaki uyumu garanti eder; sizin kısıtlarınızı ya da bir sağlayıcının hangi kombinasyonları reddettiğini bilmez.

Çevrimiçi araç hangi işler için doğru seçim?

Çevrimiçi araç, bir kişi düğmeye bastığında kayıt üreten bir sayfadır. Kurulum gerektirmez, kimlik bilgisi istemez, bir paket yöneticisine dokunmaz.

Bu onu tek seferlik insan işleri için doğru araç yapar: bir hata raporundan test senaryosu yazan kalite mühendisi, sahte profilini dolduran tasarımcı, müşterinin ekran görüntüsünü yeniden üreten destek temsilcisi, bir forma yapıştırıp formun nasıl davrandığını görmek isteyen geliştirici. Hız işin tamamıdır; bir kütüphaneye ya da komut satırına uzanmak bu durumda daha yavaştır.

Sınırlar hedef kitleyle ilgilidir. Bir tarayıcı sayfası CI’da betiklenemez ve kararlı bir anahtar sunmuyorsa tekrarlanabilir de değildir; bu da onu bir örnek için uygun, bir fixture olarak ise kullanılamaz kılar. Tamamen tarayıcıda çalışan üretimin yine de yararlı bir özelliği vardır: hiçbir şey yüklenmez, dolayısıyla bir kayıt veri işleme sorusu doğurmadan bir demo ortamına yapıştırılabilir.

Bir aracı değerlendirirken sorulacak ilk soru bu yüzden yetenek listesi değil, çalışma biçimidir. Kayıt tarayıcıda mı üretiliyor, yoksa sunucuya mı gönderiliyor? Anahtar kabul ediyor mu? Aynı anahtar aynı kaydı geri veriyor mu? Bu üç sorunun cevabı, aracın hangi işe uyduğunu yetenek listesinden daha hızlı söyler. Üretilen verinin hangi amaçla sınırlı olduğu ise sentetik ve anonimleştirilmiş veri sayfasında ayrıntılı olarak ele alınıyor.

Aralarında nasıl seçim yapılır

Seçim kuralı, kaydın nerede kullanılacağına bağlıdır ve dört satıra iner.

Kayıt kodunuzdaki bir nesneyse, ülke pek önemli değilse ve testleriniz başkasının servisine bağlı olmadan çevrimdışı çalışmak zorundaysa kütüphaneyi kullanın. İş mantığının birim testleri için varsayılan budur.

Kaydın kendi içinde tutarlı olması gerektiğinde —şehri, idari bölümü ve posta kodu uyuşan bir adres ya da kontrol basamağı hesaplanan bir kimlik numarası— ve kendiniz kurmayacağınız ülke kapsamına ihtiyaç duyduğunuzda barındırılan ya da anahtarlı bir üretici kullanın. Entegrasyon fixture’ları, tohum verisi ve makinenizden çıkan her şey için varsayılan budur. Dışa aktarma biçimleri de burada önemlidir: CSV, JSON, NDJSON ve SQL çıktısı, tek bir üretim koşusunun bir fixture dosyasını, bir kuyruğu ve bir veritabanı geri yüklemesini besleyebileceği anlamına gelir. Toplu üretim de aynı nedenle önemlidir; bir staging tablosunu arayüzden satır satır tohumlamak kimsenin tekrarladığı bir iş akışı değildir.

Bir insanın şimdi tek bir kayda ihtiyacı olduğunda ve o kayıt iddia edilmek yerine okunacaksa çevrimiçi aracı kullanın.

Çoğu ekip üçünden ikisine ihtiyaç duyar ve ayrım ilk bakışta göründüğünden daha temizdir. Kütüphaneyi birim testlerinin içinde kullanın: orada kayıt nadiren test edilen fonksiyonun dışına çıkar, doğru şekle sahip bir dize ve boş olmayan bir ad yeterlidir, hız önemlidir ve ağ döngünün dışında kalmalıdır.

Sınırı aşan her şey için anahtarlı bir üretici kullanın. Bir entegrasyon fixture’ı bir veritabanına, bir kuyruğa, bir kargo API’sine ya da bir ödeme korumalı alanına iner ve bunların her biri kütüphanenin hiç modellemediği ilişkileri denetler.

İkisi arasındaki dikiş, dışa aktarma adımıdır: entegrasyon kümesini bir kez üretin, onu üreten anahtarın yanına NDJSON ya da SQL olarak işleyin ve CI’ın ağ erişimi olmadan okumasına izin verin. Şema değişikliği o zaman satırları elle düzenlemek yerine yeniden üretmekle halledilir.

Bir üreticinin ülke kapsamı nasıl değerlendirilir?

Kapsam iddialarını ortaya atmak kolay, denetlemek zordur: bir üretici yüz ülke listeleyip yine de sevkiyat yaptığınız on ülke için işe yaramaz olabilir. Sayıya değil, verinin yapısına bakın.

• Yönetim kademesi ne kadar derine iniyor? Üretici birinci düzey idari bölümleri ve büyük ya da federal ülkeler için ilçe gibi ikinci düzeyi biliyor mu? Tek birim “eyalet” ise, bir vergi yargı bölgesine çözülmesi gereken adres bunu yapamaz.
• Posta kodu şehre ait mi? Bir ülke için on kayıt çekin ve her posta kodunun kaç şehirle göründüğünü sayın. Tahsis edilmiş kodlar bir şehri ya da küçük bir teslimat alanını kapsar; desenle üretilen kodlar ülke çapında çakışır.
• Kimlik numarasının kontrol basamağı hesaplanıyor mu, yoksa yalnızca uzunluğu mu doğru? On beş haneli bir dize bir şekildir. İlk dokuz haneden türetilmiş iki kontrol basamağı olan bir numara ise bir KYC akışının kabul edeceği bir numaradır.
• Algoritmasız durum dürüstçe etiketleniyor mu? Bir ülkenin kayıtlarının yalnızca biçim olduğuna dair açık bir ifade arayın. Bu noktada geçerliliği ima eden bir üretici, açıkça cevap verenden daha kötüdür, çünkü üzerine test kuracağınız şey yanlış iddiadır.

Bu denetimi en yoğun on ülkeniz için üretilmiş bir parti üzerinde sorgu olarak çalıştırın. Kapsam sorusu böylece bir broşür cümlesi olmaktan çıkar ve ölçülebilir bir sonuca dönüşür. Alanlar arası tutarlılığı nasıl denetleyeceğiniz kimlik alanlarının tutarlılığı sayfasında anlatılıyor; farklı ülkelerin kimlik alanlarının uzunluk ve biçim farkları ise ülkeye göre kimlik uzunluğu sayfasında toplanmıştır.

Tekrarlanabilirlik neyi garanti eder, neyi etmez?

Yukarıdakilerin tamamı tek bir soruya indirgenir: yarın aynı kaydı geri alabilir misiniz?

Bir kütüphane “evet, tohum ve sürüm aynıysa ve kaydı tutarlı kılan bağı yazdıysanız” der. Anahtarlı bir üretici “evet, aynı anahtar için” der. Tohumlanmamış bir çevrimiçi araç “hayır” der. Bir test fixture’ı için yalnızca ilk iki cevap kullanılabilir ve ikincisini uygulamak daha kolaydır, çünkü anahtar bir lockfile’da yaşamak yerine testle birlikte yol alır.

Hangi vaadi satın aldığınızı bilmek işe yarar, çünkü tekrarlanabilir olmak tek bir şey değildir. Tohum, tek bir sürümün dizisini yinelenebilir kılar; bir kütüphanenin sunduğu budur ve tohumun bir teste değil bir lockfile’a bağlı olmasının nedenidir. Anahtar daha güçlüdür: aynı anahtar, aynı ülke, aynı kayıt; alttaki havuzlar hangi sırada durursa dursun. Yalnızca ikincisi bir teste yazılıp orada bırakılabilir.

Bunların hiçbiri kaydın gerçekçi olduğunu, posta kodunun var olduğunu ya da kimlik numarasının bir zamanlar verilmiş olduğunu vaat etmez. Tekrarlanabilirlik aynı baytları geri almakla ilgilidir, baytların doğru olmasıyla değil.

Hangisini seçerseniz seçin, fixture’ın neyi garanti ettiğini yazın. Geçerli bir adres gibi biçimlenmiş bir kayıt ile kendi içinde tutarlı bir kayıt farklı vaatlerdir ve aralarındaki boşluk, test paketlerinin gerçeklikten koptuğu tam yerdir.

Üretici değiştirmek neden bir fixture göçüdür?

Üretici değiştirmek bir fixture göçüdür ve zaman kod değişikliğine değil göçe gider.

Bir kütüphaneden anahtarlı bir üreticiye geçerseniz, tohumlanmış bir dizi üzerine kurulu her fixture’ın anahtar olarak yeniden ifade edilmesi gerekir. Mekanik kısım, anahtarları atayan ve dosyaları yeniden yazan bir betiktir. Pahalı kısım, sessizce eski değerlere bağlı kalmış iddialardır: bir telefon numarasının beklenen uzunluğu, üreticinin kullanıverdiği bir alan adındaki e-posta adresi. Bunlar göçle ilgisiz nedenlerle başarısız olur ve bu yüzden en çok zaman kaybettiren arızalardır.

Ters yöne gitmek, kayıt düzeyi tutarlılığı çevrimdışı hızla değişir. Tutarlı bir demete güvenen her yer, artık daha önce yazmak zorunda olmadığınız bağı gerektirir.

Her iki yönde de kontrol listesi kısadır. Her fixture’ı listeleyin. Üretilmiş içeriğe dokunan her iddiayı listeleyin. Her birini bir şekli mi yoksa bir sabiti mi test ettiği şeklinde işaretleyin. Yalnızca sabit iddialarının göç etmesi gerekir; ve eğer paketinizde neredeyse hiç şekil iddiası yoksa, asıl bulgu bu eksikliktir.

Son olarak, üreticinin neyden inşa edildiğini bilmek de değerlidir. Açık lisanslı referans veri kaynakları, coğrafi adlar için GeoNames gibi veri kümeleri, yerel ayar kuralları için Unicode CLDR ve yapılandırılmış veri için Wikidata, ülke yapısının uydurulmuş dizeler değil referans verisi olduğu anlamına gelir; bir şehir ile posta kodunun uyuştuğuna güvenilebilmesinin tek nedeni budur. Fixture’ların nasıl saklanacağı ve sürümleneceği test fixture’larında kimlik verisi sayfasında anlatılıyor.

Sonraki adımlar

Önce bugünkü fixture’larınızı envanterleyin: hangileri yalnızca bir şekle dayanıyor, hangileri üretilmiş bir sabite bağlı. Sabite bağlı olanları sayın; göç maliyetiniz aşağı yukarı bu sayıdır. Ardından entegrasyon kümeniz için bir ülke seçin, tek bir anahtarla üretin ve dışa aktarılan dosyayı CI’a ağ erişimi olmadan okutun. Bu iki adım, üç yol arasındaki sınırı kendi deponuzda görünür kılar.

Kimlik ve adres kayıtlarını hızlıca denemek isterseniz kimlik üreticisi tek bir kaydı anahtar, ülke ve alan seçimleriyle üretir; aynı kaydı tekrar çağırmak aynı sonucu verdiği için bir testte sabit değer yerine anahtar saklayabilirsiniz. Üretilen kayıtlar tamamen kurgusaldır ve yalnızca yazılım testi için tasarlanmıştır; gerçek bir kişiyi, gerçek bir adresi veya gerçek bir kurumu tanımlamaz, resmî bir belge yerine geçmez ve hiçbir hukuki ya da idari işlemde dayanak olarak kullanılamaz. Bunları üretim verisi yerine değil, yalnızca test girdisi olarak kullanın.