اختبارات التحقق

الـ QC للتحقّق يُتحقَّق أن كل إدخال نموذج يُنَفِّذ قيوده الموثَّقة — النوع، الطول، الصيغة، النطاق، required-ness، قواعد cross-field — وأن حالات الخطأ تَرسم في كلّ من EN و AR مع رسائل واضحة، صحيحة-المحلّية. عيوب التحقّق ثاني-أكثر-سبب-شيوعاً لانكسار خط أنابيب admin بعد السلامة المرجعية.

شريط فحص لكل إدخال

• الحقول المطلوبة: submit فارغ يَعرض الخطأ inline في كلّ من EN + AR؛ زرّ submit لا يَفعل no-op صامتاً.
• طول النصّ: إدخال يَتجاوز max-length الموثَّق مُقَصَّص أو مرفوض مع رسالة واضحة "max X characters" (ليست "invalid input" عامة).
• صيغة البريد: regex قياسي مُمتثِل-RFC. "user@" + "user@domain" + "user@domain." كلّها مرفوضة. "user@domain.co.uk" + "user+tag@domain.com" مقبولة.
• صيغة URL: يجب أن يَبدأ بـ http:// أو https://، يجب أن يَحتوي على نقطة واحدة على الأقل في الـ host. الفراغ الخلفي مُقَطَّع؛ خلاف ذلك لا تصحيح تلقائي.
• صيغة التاريخ: ISO 8601 فقط (YYYY-MM-DDTHH:mm:ss±HH:mm). منتقيات التاريخ تُصدر هذه الصيغة؛ الإدخال اليدوي يَرفض الصيغ المفكوكة.
• قواعد cross-field تَرسم في اللحظة الصحيحة: endDate < startDate يَومض الخطأ على حقل endDate (ليس عند submit فقط)؛ applicationDeadline > startDate نفس المعالجة.
• الحقول bilingual: متغيّر AR مفقود لعنوان مطلوب يَفشل تماماً كـ EN مفقود. لا fallback إلى "EN كافٍ".