Tüm makaleler

Mock JSON Generator: sahte veriler ne işe yarar

Frontend geliştirme genellikle backend gerçek verileri sunmaya hazır olmadan önce başlar. Çalışan bir API'yi beklemek yerine, doğru şekilde gerçekçi test JSON verileri üretip hemen çalışmaya başlayabilirsiniz.

Sahte veri nedir

Mock JSON, üretilmiş ama yapısal olarak inandırıcı verilerdir: gerçek isimler gibi görünen isimler, doğru formatta tarihler, olması gerektiği gibi görünen kimlikler. "test123" gibi yer tutucu değerlerin aksine, gerçekçi mocklar arayüzün uzun isimleri, boş alanları veya belirli tarih formatlarını doğru işleyip işlemediğini hemen gösterir.

Buna neden ihtiyaç duyulur

  • Backend ekibi API'yi bitirmeden önce arayüz geliştirmeye başlamak.
  • Gerçek bir veritabanını doldurmaya gerek kalmadan arayüzün çok sayıda kayıtla nasıl davrandığını test etmek.
  • Gerçek kullanıcı verilerini açığa çıkarmadan bir demo veya prototip oluşturmak.
  • Harici bir hizmetin veya veritabanının durumuna bağlı olmayan otomatik testler yazmak.

Türkçe adres ve telefon biçimlerinin kendine has kuralları var

Türkiye'de adresler Mahalle, Sokak/Cadde, kapı ve daire numarası şeklinde katmanlı yazılır; bu, düz bir street alanına sığmayan bir yapıdır. Posta kodu 5 haneli olup şehir merkezine göre değişir, telefon numaraları ise +90 ülke kodunun ardından alan koduyla yazılır — İstanbul için +90 212 (Avrupa yakası) veya +90 216 (Anadolu yakası) gibi. Ayrıca Türkçedeki ı, ğ, ş, ö, ü, ç gibi harfler ASCII'de karşılığı olmayan karakterlerdir; bir mock şablonu bu harfleri düzgün üretmezse veya yalnızca ASCII harflerle isim oluşturursa, çıktı gerçekçi bir Türkçe veriden çok İngilizce bir yer tutucuya benzer.

Nelere dikkat edilmeli

Sahte veriler, gerçek verilerin şeklini ve türlerini iyi yeniden üretir, ama iş mantığını veya kayıtlar arasındaki ilişkileri değil. Üretime geçmeden önce kodun yine de gerçek bir API'ye karşı test edilmesi gerekir — mocklar yalnızca geliştirmenin erken aşamalarını hızlandırır.

Moklarda gerçekçi uç durumlar

İyi bir mock üreteci, kasıtlı olarak "elverişsiz" değerler içerir — çok uzun isimler, boş dizeler, Unicode karakterleri, sıfır veya negatif sayılar, aralığın sınırındaki tarihler. Tam olarak bu tür değerler, geliştiricinin yalnızca "John Doe" gibi "elverişli" verilerle test ettiği arayüzü veya mantığı en sık bozar — bu yüzden mockların rastgeleliği, her seferinde aynı test örneğinden daha kullanışlıdır.

Aracı dene