أساسيات اختبار تطبيقات Android

توضّح هذه الصفحة المبادئ الأساسية لاختبار تطبيقات Android، بما في ذلك أفضل الممارسات الأساسية وفوائدها.

فوائد الاختبار

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

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

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

أنواع الاختبارات في Android

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

الموضوع

على سبيل المثال، هناك أنواع مختلفة من الاختبارات حسب الموضوع:

• الاختبار الوظيفي: هل يؤدي تطبيقي ما يُفترض أن يؤديه؟
• اختبار الأداء: هل يؤدي التطبيق ما يُفترض أن يؤديه بسرعة وكفاءة؟
• اختبار تسهيل الاستخدام: هل يعمل التطبيق بشكل جيد مع خدمات تسهيل الاستخدام؟
• اختبار التوافق: هل يعمل التطبيق بشكل جيد على كل جهاز ومستوى واجهة برمجة تطبيقات؟

النطاق

تختلف الاختبارات أيضًا حسب الحجم أو درجة العزل:

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

الشكل 1: نطاقات الاختبار في تطبيق نموذجي.

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

الاختبارات التي تقيس حالة التطبيق مقابل الاختبارات المحلية

يمكنك إجراء الاختبارات على جهاز Android أو على جهاز كمبيوتر آخر:

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

الشكل 2: أنواع مختلفة من الاختبارات حسب مكان إجرائها.

ليست كل اختبارات الوحدة محلية، وليست كل اختبارات من البداية إلى النهاية يتم إجراؤها على جهاز. على سبيل المثال:

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

أمثلة

توضّح المقتطفات التالية كيفية التفاعل مع واجهة المستخدم في اختبار واجهة مستخدم يقيس حالة التطبيق ينقر على أحد العناصر ويتحقّق من عرض عنصر آخر.

مظهر إسبرسو

// When the Continue button is clicked
onView(withText("Continue"))
    .perform(click())

// Then the Welcome screen is displayed
onView(withText("Welcome"))
    .check(matches(isDisplayed()))

واجهة مستخدم Compose

// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()

// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()

يعرض هذا المقتطف جزءًا من اختبار وحدة لـ ViewModel (اختبار محلي من جهة المضيف):

// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)

// When data is loaded
viewModel.loadData()

// Then it should be exposing data
assertTrue(viewModel.data != null)

هندسة معمارية قابلة للاختبار

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

تنتج الهندسة المعمارية غير القابلة للاختبار ما يلي:

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

لمزيد من المعلومات حول إرشادات الهندسة المعمارية، يُرجى الاطّلاع على دليل الهندسة المعمارية للتطبيقات.

أساليب الفصل

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

تشمل تقنيات الفصل الشائعة ما يلي:

• تقسيم التطبيق إلى طبقات مثل طبقة العرض وطبقة النطاق وطبقة البيانات يمكنك أيضًا تقسيم التطبيق إلى وحدات، واحدة لكل ميزة.
• تجنَّب إضافة منطق إلى الكيانات التي تتضمّن تبعيات كبيرة، مثل الأنشطة والأجزاء. استخدِم هذه الفئات كنقاط دخول إلى إطار العمل وانقِل واجهة المستخدم والمنطق التجاري إلى مكان آخر، مثل عنصر Composable أو ViewModel أو طبقة النطاق.
• تجنَّب التبعيات المباشرة لإطار العمل في الفئات التي تحتوي على منطق تجاري. على سبيل المثال، لا تستخدِم سياقات Android في ViewModels.
• اجعل من السهل استبدال التبعيات. على سبيل المثال، استخدِم الواجهات بدلاً من عمليات التنفيذ الملموسة. استخدِم ميزة "إدراج التبعية" حتى إذا كنت لا تستخدِم إطار عمل "إدراج التبعية".

الخطوات التالية

بعد أن عرفت سبب إجراء الاختبارات والنوعَين الرئيسيين من الاختبارات، يمكنك قراءة ما يجب اختباره أو التعرّف على استراتيجيات الاختبار

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