تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
ويعتمد ما يجب اختباره على عوامل مثل نوع التطبيق وفريق التطوير ومقدار الرمز القديم والبنية المستخدمة. تحدد الأقسام التالية ما قد يرغب المبتدئ في التفكير فيه عند التخطيط
لما سيختبره في تطبيقه.
تنظيم أدلة الاختبار
يحتوي المشروع النموذجي في Android Studio على دليلين لإجراء الاختبارات بناءً على بيئة التنفيذ. نظّم اختباراتك في الأدلة التالية كما هو موضح:
يجب أن يتضمّن دليل androidTest اختبارات يتم تنفيذها على أجهزة حقيقية أو افتراضية. تتضمّن هذه الاختبارات اختبارات الدمج والاختبارات الشاملة
واختبارات أخرى لا يمكن فيها لجهاز JVM وحده التحقّق من صحة وظائف تطبيقك.
يجب أن يتضمّن دليل test الاختبارات التي يتم إجراؤها على جهازك المحلي،
مثل اختبارات الوحدات. على عكس ما سبق، يمكن أن تكون هذه اختبارات يتم تشغيلها على جهاز JVM محلي.
اختبارات الوحدات الأساسية
وعند اتّباع أفضل الممارسات، يجب التأكّد من استخدام اختبارات الوحدات في الحالات التالية:
اختبارات الوحدات لـ ViewModels أو المقدمين.
اختبارات الوحدات لطبقة البيانات، وخاصة المستودعات ينبغي أن تكون معظم طبقة
البيانات مستقلة عن النظام الأساسي. يؤدي القيام بذلك إلى تمكين الضعف التجريبي من
استبدال وحدات قاعدة البيانات ومصادر البيانات البعيدة في الاختبارات. يمكنك الاطّلاع على دليل
استخدام الضعف في الاختبار في Android
اختبارات الوحدات لطبقات أخرى مستقلة عن النظام الأساسي مثل طبقة النطاق، كما هو الحال مع حالات الاستخدام والتفاعلات.
اختبارات الوحداتلفئات الأداة، مثل معالجة السلاسل والرياضيات.
حالات حافة الاختبار
ويجب أن تركز اختبارات الوحدات على الحالات العادية والحالات الهامشية. الحالات الهامشية هي سيناريوهات غير شائعة من غير المرجح
أن يصادفها المختبرون البشريون والاختبارات الأكبر. وتشمل الأمثلة ما يلي:
العمليات الحسابية باستخدام الأرقام السالبة والصفر وشروط الحدود.
جميع الأخطاء المحتملة في الاتصال بالشبكة.
البيانات التالفة، مثل تنسيق JSON المكتوب بشكلٍ غير صحيح
محاكاة مساحة التخزين الكاملة عند الحفظ في ملف.
إعادة إنشاء كائن في منتصف العملية (مثل نشاط عند تدوير الجهاز).
اختبارات الوحدات التي يجب تجنُّبها
يجب تجنُّب بعض اختبارات الوحدات بسبب قيمتها المنخفضة:
اختبارات تتحقق من التشغيل الصحيح لإطار العمل أو المكتبة، وليس التعليمات البرمجية.
يجب ألّا يكون لنقاط دخول إطار العمل، مثل الأنشطة أو الأجزاء أو الخدمات، منطق في العمل، لذا يجب عدم إعطاء الأولوية لاختبار الوحدات. لا قيمة لاختبارات الوحدة
للأنشطة، لأنها ستتناول في الغالب رمز إطار العمل
وتتطلب إعدادًا أكثر تعمقًا. يمكن للاختبارات الآلية مثل اختبارات واجهة
المستخدم أن تغطي هذه الفئات.
اختبارات واجهة المستخدم
هناك عدة أنواع من اختبارات واجهة المستخدم التي يجب عليك استخدامها:
تتحقّق اختبارات واجهة مستخدم الشاشة من تفاعلات المستخدم المهمة في شاشة واحدة. فهم ينفذون إجراءات مثل النقر على الأزرار وكتابة النماذج والتحقق من الحالات المرئية. يعد اختبار واحد لكل شاشة نقطة بداية جيدة.
اختبارات تدفق المستخدم أو اختبارات التنقل، التي تغطي المسارات الأكثر شيوعًا. تحاكي هذه الاختبارات المستخدم الذي يتحرك خلال تدفق تنقل. فهي اختبارات بسيطة، ومفيدة للتحقق من أعطال وقت التشغيل في التهيئة.
الاختبارات الأخرى
هناك اختبارات أكثر تخصصًا مثل اختبارات لقطات الشاشة واختبارات الأداء
واختبارات القرود. يمكنك أيضًا تصنيف الاختبارات حسب الغرض، مثل الانحدار وإمكانية الوصول والتوافق.
محتوى إضافي للقراءة
لإجراء الاختبار بمعزل عن الآخر، تحتاج غالبًا إلى استبدال تبعيات الموضوع الذي يخضع للاختبار بتبعيات مزيفة أو وهمية، تسمى "الاختبار المزدوج"
بشكل عام. يُرجى مواصلة القراءة عنها في قسم استخدام الضعف في الاختبار في Android.
إذا كنت تريد معرفة كيفية إنشاء اختبارات الوحدات وواجهة المستخدم، يمكنك الاطّلاع على دروس اختبار الرموز.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# What to test in Android\n\nWhat you should test depends on factors such as the type of app, the development\nteam, the amount of legacy code, and the architecture used. The following\nsections outline what a beginner might want to consider when planning what to\ntest in their app.\n\nOrganization of test directories\n--------------------------------\n\nA typical project in Android Studio contains two directories that hold tests\ndepending on their execution environment. Organize your tests in the following\ndirectories as described:\n\n- The `androidTest` directory should contain the tests that run on real or virtual devices. Such tests include integration tests, end-to-end tests, and other tests where the JVM alone cannot validate your app's functionality.\n- The `test`directory should contain the tests that run on your local machine, such as unit tests. In contrast to the above, these can be tests that run on a local JVM.\n\nEssential unit tests\n--------------------\n\nWhen following best practice, you should ensure you use unit tests in the\nfollowing cases:\n\n- **Unit tests** for **ViewModels**, or presenters.\n- **Unit tests** for the **data** layer, especially repositories. Most of the data layer should be platform-independent. Doing so enables test doubles to replace database modules and remote data sources in tests. See the guide on [using test doubles in Android](/training/testing/fundamentals/test-doubles)\n- **Unit tests** for other platform-independent layers such as the **Domain** layer, as with use cases and interactors.\n- **Unit tests** for **utility classes** such as string manipulation and math.\n\n### Testing Edge Cases\n\nUnit tests should focus on both normal and edge cases. Edge cases are uncommon\nscenarios that human testers and larger tests are unlikely to catch. Examples\ninclude the following:\n\n- Math operations using negative numbers, zero, and [boundary\n conditions](https://en.wikipedia.org/wiki/Off-by-one_error).\n- All the possible network connection errors.\n- Corrupted data, such as malformed JSON.\n- Simulating full storage when saving to a file.\n- Object recreated in the middle of a process (such as an activity when the device is rotated).\n\n### Unit Tests to Avoid\n\nSome unit tests should be avoided because of their low value:\n\n- Tests that verify the correct operation of the framework or a library, not your code.\n- Framework entry points such as *activities, fragments, or services* should not have business logic so unit testing shouldn't be a priority. Unit tests for activities have little value, because they would cover mostly framework code and they require a more involved setup. Instrumented tests such as UI tests can cover these classes.\n\nUI tests\n--------\n\nThere are several types of UI tests you should employ:\n\n- **Screen UI tests** check critical user interactions in a single screen. They perform actions such as clicking on buttons, typing in forms, and checking visible states. One test class per screen is a good starting point.\n- **User flow tests** or **Navigation tests**, covering most common paths. These tests simulate a user moving through a navigation flow. They are simple tests, useful for checking for run-time crashes in initialization.\n\n| **Note:** Test coverage is a metric that some testing tools can calculate, and indicates how much of your code is visited by your tests. It can detect untested portions of the codebase, but it should not be used as the only metric to claim a good testing strategy.\n\nOther tests\n-----------\n\nThere are more specialized tests such as screenshot tests, performance tests,\nand [monkey tests](/studio/test/monkey). You can also categorize tests by purpose, such as\nregressions, accessibility, and compatibility.\n\nFurther reading\n---------------\n\nIn order to test in isolation, you oftentimes need to replace the dependencies\nof the subject under test with fake or mock dependencies, called \"Test doubles\"\nin general. Continue reading about them in [Using test doubles in Android](/training/testing/fundamentals/test-doubles).\n\nIf you want to learn how to create unit and UI tests, check out the [Testing\ncodelabs](/codelabs/advanced-android-kotlin-training-testing-basics)."]]
