طرق التنفيذ

بدائل لمصادر عدم النشاط في اختبارات Compose: واجهات برمجة التطبيقات waitUntil (تم التعديل)

قراءة لمدة 3 دقائق
Jose Alcérreca
مهندسة علاقات المطوّرين

في هذه المقالة، ستتعرّف على كيفية استخدام واجهة برمجة التطبيقات waitUntil الاختبارية في Compose لانتظار استيفاء شروط معيّنة. وهذا بديل جيد لاستخدام Idling Resources في بعض الحالات.

[تعديل 2023] الخلاصة: استخدِم واجهات برمجة التطبيقات الجديدة waitUntil للمزامنة في اختبارات Compose (الإصدار 1.4.0 والإصدارات الأحدث).


ما هي المزامنة؟

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

اضغط على المفتاح Enter أو انقر لعرض الصورة بالحجم الكامل

large_0_9n_Nqkt_HHUTOQ_In_AI_b113b43bcf.png
نطاقات اختبار مختلفة في تطبيق

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

اضغط على المفتاح Enter أو انقر لعرض الصورة بالحجم الكامل

large_correct_b1a355f41b.webp
مزامنة صحيحة بين الاختبار والتطبيق

androidx.test، وبالتالي Compose Test، تستخدم بعض الحيل في الخلفية حتى لا تقلق كثيرًا بشأن ذلك. على سبيل المثال، إذا كانت سلسلة التعليمات الرئيسية مشغولة، يتوقف الاختبار مؤقتًا إلى أن يتمكّن من تنفيذ السطر التالي.

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

الخيار 1: الموارد غير النشطة

‫Idling Resources هي إحدى ميزات Espresso التي تتيح لك، بصفتك المطوِّر، تحديد الوقت الذي يكون فيه التطبيق مشغولاً. يمكنك استخدامها بطريقتَين:

1. تثبيتها في إطار العمل أو المكتبة التي تنفّذ عملاً لا يمكن للاختبار رؤيته

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

2. تعديل الرمز البرمجي قيد الاختبار لعرض معلومات صريحة حول ما إذا كان تطبيقك مشغولاً أم لا

على سبيل المثال، يمكنك تعديل المستودع (أو عنصر الاختبار البديل) للإشارة إلى أنّه مشغول أثناء تحميل البيانات من مصدر بيانات:

وهذا ليس مثاليًا لأنّك ستلوّث رمز الإنتاج أو ستنشئ بدائل اختبارية معقّدة، وهناك بعض الحالات التي يصعب فيها تثبيتها. على سبيل المثال، كيف يمكنك استخدام Idling Resources في Kotlin Flow؟ أيّ تحديث هو التحديث النهائي؟

بدلاً من ذلك، يمكننا الانتظار.

الخيار 2: انتظار النتائج… بالطريقة الخاطئة

عادةً ما يكون تحميل البيانات سريعًا، خاصةً عند استخدام بيانات وهمية، فلماذا نضيّع الوقت في انتظار الموارد غير النشطة بينما يمكننا ببساطة إيقاف الاختبار مؤقتًا لبضع ثوانٍ؟

سيؤدي ذلك إلى تشغيل الاختبار بشكل أبطأ من اللازم أو عدم اجتيازه. عندما يكون لديك المئات أو الآلاف من اختبارات واجهة المستخدم، من المهم أن تكون الاختبارات بأسرع ما يمكن.

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

0_DOCdjq-JpPDGV5OB.png

الخيار 3: الانتظار بالطريقة الصحيحة

إذا كنت لا تريد تعديل الرمز قيد الاختبار لمعرفة وقت انشغاله، يمكنك الانتظار إلى أن يتم استيفاء شرط معيّن بدلاً من الانتظار لمدة زمنية عشوائية.

1_jIYFxE4qlHXMi2SwW6JemA.png

في Compose، يمكنك الاستفادة من الدالة waitUntil التي تستخدم دالة أخرى تعرض قيمة منطقية.

تعديل بتاريخ 22/03/2023: بدءًا من الإصدار 1.4.0 من Compose، أضفنا مجموعة جديدة من واجهات برمجة التطبيقات waitUntil:

[Before 1.4.0: Use these helpers: waitUntilExists, waitUntilNodeCount]

…واستخدِمها على النحو التالي:

استخدِم واجهات برمجة التطبيقات هذه فقط عندما تحتاج إلى مزامنة الاختبار مع واجهة المستخدم. تؤدي المزامنة في كل استطلاع لبيان الاختبار إلى تلويث رمز الاختبار بلا داعٍ، ما يصعّب الحفاظ عليه.

متى يجب استخدامها؟ ومن حالات الاستخدام الجيدة لها تحميل البيانات من عنصر قابل للمراقبة (باستخدام LiveData أو Kotlin Flow أو RxJava). عندما تحتاج واجهة المستخدم إلى تلقّي عدّة تحديثات قبل اعتبارها غير نشطة، قد تحتاج إلى تبسيط المزامنة باستخدام waitUntil.

على سبيل المثال، عند جمع Flow من طريقة عرض:

ويمكنك إرسال عناصر متعدّدة إليه:

إذا استغرقت repository وقتًا غير محدّد للرجوع مع النتيجة الأولى، سيعتقد إطار عمل الاختبار أنّ "جارٍ التحميل" هي حالة عدم النشاط (القيمة الأولية المعيّنة في collectAsState) وسيواصل تنفيذ العبارة التالية.

لذلك، يمكنك جعل الاختبار أكثر موثوقية إذا تأكّدت من أنّ واجهة المستخدم لا تعرض مؤشر التحميل:


اختبار سعيد… انتظروا المفاجأة…


ترخيص مقتطفات الرمز:

Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0
تأليف:

متابعة القراءة