ترحيل اختبارات Flutter من Firebase Test Lab قبل إيقافه: خطة عملية بلا تعطيل للتسليم

أعلنت Google أن Firebase Test Lab أصبح خدمة مهملة وسيُغلق بالكامل في 30 سبتمبر 2027، ودعت الفرق إلى نقل تدفقات الاختبار إلى Google Cloud Developer Device Platform (DDP). لا يعني ذلك أن اختباراتك ستتوقف اليوم، لكنه يعني أن أوامر CI، ومصفوفات الأجهزة، ومكان حفظ النتائج، وطريقة تشخيص الفشل تحتاج إلى مراجعة مبكرة.

هذه المقالة تقترح خطة عملية لتطبيق Flutter: حافظ على هرم الاختبارات داخل المشروع، وانقل فقط الطبقة التي تحتاج أجهزة سحابية، ثم شغّل النظامين بالتوازي قبل التحويل النهائي. الهدف ليس تبديل أمر بآخر، بل حماية دورة الإصدار من مفاجآت الأدوات الجديدة.

تنبيه: منصة DDP في مرحلة Preview وقت كتابة المقال. أوامر Android تستخدم gcloud beta device-run، أما أمر iOS XCTest فما زال على مسار alpha (gcloud alpha device-run sessions submit xctest). تحقّق من الملاءمة، والتكلفة، والدعم قبل اعتمادها كبوابة إصدار وحيدة.

ما الذي تغيّر فعليًا؟

وفق الأسئلة الشائعة الرسمية، سيستمر تنفيذ الاختبارات على Firebase Test Lab حتى 30 سبتمبر 2027، ثم تُغلق الواجهة وواجهة API. البديل المعلن هو Developer Device Platform، الذي يضم Device Run لتنفيذ الاختبارات وDevice Streaming للتعامل مع أجهزة Android فعلية عن بُعد.

توضح وثيقة الترحيل الرسمية أن Device Run يدعم في نسخة Preview اختبارات Android Instrumentation وiOS XCTest. كما يتغير شكل الأوامر من:

bashgcloud firebase test android run --type=instrumentation ...

إلى نمط قائم على الجلسات:

bashgcloud beta device-run sessions submit instrumentation ...

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

ابدأ من هرم الاختبار، لا من مزود الأجهزة

توثيق Flutter يقسم الاختبارات إلى ثلاث طبقات: unit لاختبار دالة أو فئة، وwidget لاختبار مكوّن واجهة، وintegration لاختبار التطبيق كاملًا أو جزء كبير منه. ويوصي بكثرة اختبارات unit وwidget مع عدد كافٍ من اختبارات integration للمسارات المهمة، لأن اختبارات التكامل أبطأ وأعلى تكلفة في الصيانة.

هذه القاعدة تصبح أهم أثناء الترحيل. لا تدفع كل التحقق إلى مزرعة أجهزة سحابية. يمكن توزيع المسؤولية هكذا:

1. Unit: قواعد المجال، وحالات BLoC أو Cubit، والتحويل والتحقق من المدخلات.
2. Widget: حالات التحميل والخطأ والبيانات، واتجاه RTL، والأحجام المختلفة، والوصول الأساسي.
3. Integration محلي: رحلة قصيرة مثل تسجيل الدخول أو إنشاء طلب باستخدام محاكي Android وiOS Simulator.
4. أجهزة سحابية: المسارات الحساسة لاختلاف الجهاز أو نظام التشغيل، مثل الكاميرا والإشعارات والأذونات والأداء.

وهنا قيد مهم: حزمة Flutter الرسمية integration_test لا تتفاعل مع واجهة النظام الأصلية مثل نوافذ الأذونات والإشعارات وplatform views. تقترح وثائق Flutter إطار Patrol عندما تحتاج هذه التفاعلات. هذا قرار في تصميم الاختبار، وليس تفصيلًا يحله نقل المزود تلقائيًا.

خطة ترحيل من ست خطوات

1. جرد ما يعمل اليوم

ابحث في ملفات CI والسكربتات عن gcloud firebase test وملفات Flank وأسماء الأجهزة وملفات APK/IPA ومسارات النتائج. سجّل لكل مهمة:

• نوع الاختبار والمنصة؛
• الأجهزة وإصدارات النظام واللغة والاتجاه؛
• المتغيرات والملفات الإضافية؛
• المهلة والتقسيم وإعادة المحاولة؛
• أين تُحفظ الفيديوهات والسجلات ونتائج JUnit؛
• ما الذي يجعل المهمة ناجحة أو فاشلة.

هذا الجرد هو خط الأساس الذي ستقارن به DDP. من دونه قد يمر الترحيل تقنيًا بينما تختفي تغطية جهاز أو ملف تشخيص تعتمد عليه.

2. قلّل المصفوفة إلى ما يغيّر القرار

مصفوفة ضخمة في كل pull request تبطئ الملاحظات وتزيد الضوضاء. استخدم طبقات:

• عند كل تغيير: unit وwidget واختبار تكامل سريع على هدف واحد؛
• قبل الدمج أو ليلًا: مجموعة أوسع من إصدارات Android وأحجام الشاشات؛
• قبل الإصدار: أجهزة فعلية تمثل المخاطر الأعلى، إضافة إلى iOS حيث يلزم.

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

3. افصل نية الاختبار عن أمر المزود

ضع أوامر السحابة خلف سكربت صغير أو مهمة CI باسم مستقر مثل cloud_device_smoke. اجعل ملفات البناء، واسم مجموعة الاختبارات، والمصفوفة، ومجلد النتائج مدخلات واضحة. بذلك تتغير طبقة الموفر من Test Lab إلى Device Run من دون إعادة كتابة خط التسليم كله.

مثال هيكلي، وليس أمرًا كاملًا جاهزًا لكل مشروع:

yamlcloud_device_smoke:
  platform: android
  app: build/app/outputs/apk/release/app-release.apk
  test: build/app/outputs/apk/androidTest/release/app-release-androidTest.apk
  devices: ["DEVICE_ID_FROM_CURRENT_CATALOG"]
  artifacts: "test-results/device-run"

احتفظ بمعرّفات الأجهزة الفعلية وخيارات الأمر وفق الكتالوج الحالي والتوثيق الرسمي؛ فهي ليست ثابتة لكل مشروع.

4. ترجم الأوامر وراجع المعنى

توفر Google جدول ترجمة للأوامر والخيارات. راجع خصوصًا:

• انتقال التشغيل إلى sessions submit instrumentation أو sessions submit xctest؛
• دمج التطبيقات تحت --apps؛
• استخدام --paths-to-pull للملفات؛
• اختلاف إعادة المحاولة: عدد محاولات Test Lab لا يطابق بالضرورة عدد المحاولات الكلي في DDP؛
• حفظ النتائج في Cloud Storage وفحص الجلسة من CLI أو API.

5. شغّل النظامين بالتوازي

اختر اختبار smoke واحدًا قصيرًا وشغّله على Test Lab وDDP لفترة محدودة. قارن النتيجة، والمدة، والسجلات، والفيديو، وحالات الفشل، وسهولة إعادة التشغيل. هذا تحليل موصى به وليس ادعاءً بأن النظامين متطابقان؛ المقارنة هي التي تكشف الفجوات الخاصة بمشروعك.

لا تجعل DDP بوابة إلزامية للإصدار قبل أن تعرف سلوك Preview وحدود الدعم. ابدأ كمهمة غير مانعة، ثم ارفع أهميتها بعد ثبات النتائج.

6. حدد شروط التحويل والتراجع

اكتب شروطًا قابلة للتحقق: أهم المسارات تعمل، والنتائج محفوظة، والفشل يظهر في CI، ويمكن إعادة اختبار حالة فاشلة، والصلاحيات والتكاليف مفهومة. احتفظ بمسار Test Lab حتى يتحقق ذلك، ثم أزل الاعتماد القديم قبل موعد الإغلاق بوقت كافٍ.

ما الذي لا ينبغي خلطه مع الترحيل؟

تحسين استراتيجية الاختبار لا يضمن ظهور الموقع أو التطبيق في نتائج البحث، ولا يعالج فهرسة الموقع. كذلك نجاح الاختبارات لا يثبت جودة المنتج وحده؛ فهو يقلل مخاطر الانحدار ضمن النطاق الذي كتبته. راقب أيضًا أعطال الإنتاج، والأداء، وتعليقات المستخدمين، ومقاييس التحويل.

وبالنسبة لهذا المقال، تحسين العنوان والبنية والروابط يساعد قابلية الفهم والاكتشاف، لكن الفهرسة تعتمد على SEO تقني وملف sitemap وcanonical وإتاحة الزحف، بينما قياس الأثر يحتاج Search Console بمرور الوقت. لا توجد ضمانات للترتيب.

الخلاصة

لديك حتى 30 سبتمبر 2027، لكن أفضل وقت للبدء هو قبل أن يصبح الانتقال طارئًا. ثبّت هرم اختبارات Flutter، واجرد اعتمادك على Test Lab، وافصل نية الاختبار عن أداة المزود، ثم اختبر DDP بالتوازي على مسار صغير. بهذه الطريقة يتحول موعد الإيقاف إلى مشروع هندسي محدود بدل مخاطرة على يوم الإصدار.

إذا كنت تبني MVP أو تطبيق أعمال وتحتاج خط تسليم Flutter قابلًا للمراجعة والاختبار، يمكنك الاطلاع على خدمة تطوير MVP أو تطوير تطبيق ومنصة للأعمال، ثم مناقشة نطاق واضح قبل التنفيذ.

المصادر

• الأسئلة الشائعة الرسمية
• وثيقة الترحيل الرسمية
• جدول ترجمة للأوامر والخيارات