غالبًا ما يبدأ تطوير الواجهة الأمامية قبل أن تكون الخلفية جاهزة لتقديم بيانات حقيقية. بدلاً من انتظار API عامل، يمكنك توليد بيانات JSON اختبارية واقعية بالشكل المطلوب والبدء في العمل فورًا.
ما هي البيانات الوهمية
JSON الوهمي (mock) هو بيانات مولَّدة لكنها معقولة بنيويًا: أسماء تبدو كأسماء حقيقية، تواريخ بصيغة صحيحة، معرّفات بالشكل المناسب. على عكس قيم الحشو مثل "test123"، تُظهر البيانات الوهمية الواقعية فورًا ما إذا كانت الواجهة تتعامل بشكل صحيح مع الأسماء الطويلة أو الحقول الفارغة أو صيغ تواريخ معينة.
لماذا نحتاج ذلك
- بدء تطوير الواجهة قبل أن ينتهي فريق الخلفية من العمل على API.
- اختبار كيفية تصرف الواجهة مع عدد كبير من السجلات، دون الحاجة إلى ملء قاعدة بيانات حقيقية.
- إنشاء عرض توضيحي أو نموذج أولي دون كشف بيانات المستخدمين الحقيقية.
- كتابة اختبارات آلية لا تعتمد على حالة خدمة خارجية أو قاعدة بيانات.
لا يوجد "تنسيق عربي" واحد للعناوين وأرقام الهواتف
مولّد بيانات وهمية يفترض تنسيقًا واحدًا لكل مستخدمي اللغة العربية يقع في خطأ شائع: الدول العربية الاثنتان والعشرون تستخدم رموز اتصال دولية مختلفة تمامًا (مصر +20، السعودية +966، الإمارات +971)، وبعضها لا يملك نظام رموز بريدية شاملًا أصلًا — الإمارات، مثلًا، تعتمد على صناديق البريد (P.O. Box) بدل عنوان الشارع في أغلب المراسلات، بينما تبنّت السعودية نظام رمز بريدي من 5 أرقام رسميًا منذ 2011. حقل {{postalCode}} الذي يفترض وجود رمز بريدي دائمًا يفشل بصمت مع عنوان إماراتي واقعي.
ما يجب الانتباه إليه
تعيد البيانات الوهمية إنتاج شكل وأنواع البيانات الحقيقية جيدًا، لكن ليس منطق العمل أو العلاقات بين السجلات. قبل الانتقال إلى الإنتاج، لا يزال يجب اختبار الكود مقابل API حقيقي — البيانات الوهمية تسرّع فقط المراحل المبكرة من التطوير.
حالات حدّية واقعية في البيانات الوهمية
مولّد البيانات الوهمية الجيد يُدرج عمدًا قيمًا «غير مريحة» — أسماء طويلة جدًا، سلاسل فارغة، نصوصًا تخلط بين العربية واللاتينية في نفس الحقل، أرقامًا صفرية أو سالبة، تواريخ على حافة النطاق. هذه القيم بالذات هي الأكثر إثارة لأعطال في الواجهة أو المنطق الذي اختبره المطور فقط ببيانات «مريحة» مثل "John Doe" — لذا فإن عشوائية البيانات الوهمية أكثر فائدة من نفس المثال الاختباري في كل مرة.