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

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

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

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

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

Press enter or click to view image in full size

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

Press enter or click to view image in full size

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

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

الخيار 1: مصادر عدم النشاط

مصادر عدم النشاط هي ميزة في Espresso تتيح لكم، بصفتكم مطوّرين، تحديد متى يكون التطبيق مشغولاً. هناك طريقتان لاستخدامها:

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

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

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

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

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

بدلاً من ذلك، يمكننا الانتظار إلى أن تحدث أشياء معيّنة.

الخيار 2: الانتظار إلى أن تحدث أشياء معيّنة… بطريقة غير صحيحة

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

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

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

الخيار 3: الانتظار إلى أن تحدث أشياء معيّنة بالطريقة الصحيحة

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

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

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

[قبل الإصدار 1.4.0: استخدِموا هذه الدوال المساعدة: waitUntilExists وwaitUntilNodeCount]

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

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

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

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

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

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

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

نتمنى لكم اختبارًا سعيدًا… انتظروا قليلاً…

ترخيص مقتطفات الرموز البرمجية:

Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0