קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
מה שצריך לבדוק תלוי בגורמים כמו סוג האפליקציה, צוות הפיתוח, כמות הקוד הקודם והארכיטקטורה שבה נעשה שימוש. בקטעים הבאים מפורט מה כדאי למתחילים לקחת בחשבון כשהם מתכננים את הבדיקות באפליקציה.
ארגון של ספריות בדיקה
פרויקט רגיל ב-Android Studio מכיל שתי ספריות שמכילות בדיקות בהתאם לסביבת הביצוע שלהן. כדאי לארגן את הבדיקות בתיקיות הבאות, כפי שמתואר:
הספרייה androidTest צריכה להכיל את הבדיקות שפועלות במכשירים אמיתיים או וירטואליים. בדיקות כאלה כוללות בדיקות אינטגרציה, בדיקות מקצה לקצה ובדיקות אחרות שבהן JVM לבדו לא יכול לאמת את הפונקציונליות של האפליקציה.
הספרייה test צריכה להכיל את הבדיקות שפועלות במחשב המקומי, כמו בדיקות יחידה. בניגוד למה שצוין למעלה, אלה יכולות להיות בדיקות שפועלות ב-JVM מקומי.
בדיקות יחידה חיוניות
בהתאם לשיטות המומלצות, כדאי להשתמש בבדיקות יחידה במקרים הבאים:
בדיקות יחידה למודלים של תצוגה או למציגים.
בדיקות יחידה לשכבת הנתונים, במיוחד למאגרים. רוב שכבת הנתונים צריכה להיות עצמאית בפלטפורמה. כך אפשר להשתמש במודלים כפולים לבדיקה כדי להחליף מודולים של מסדי נתונים ומקורות נתונים מרוחקים בבדיקות. שימוש ב-test doubles ב-Android
בדיקות יחידה לשכבות אחרות שאינן תלויות בפלטפורמה, כמו השכבה Domain, כמו בתרחישי שימוש ובאינטראקטורים.
בדיקות יחידה לכיתות שירות, כמו מניפולציה של מחרוזות ומתמטיקה.
בדיקת מקרי קצה
בדיקות היחידה צריכות להתמקד גם בתרחישים רגילים וגם בתרחישים קיצוניים. תרחישים קיצוניים הם תרחישים נדירים שבודקים אנושיים ובדיקות גדולות יותר לא צפויים לזהות. דוגמאות:
פעולות מתמטיות באמצעות מספרים שליליים, אפס ותנאי גבול.
כל השגיאות האפשריות בחיבור לרשת.
נתונים פגומים, כמו JSON בפורמט שגוי.
סימולציה של נפח אחסון מלא במהלך שמירת קובץ.
אובייקט שנוצר מחדש באמצע תהליך (למשל פעילות כשהמכשיר מסתובב).
בדיקות יחידה (unit testing) שכדאי להימנע מהן
יש להימנע מחלק מבדיקות היחידה בגלל הערך הנמוך שלהן:
בדיקות שמאמתות את הפעולה הנכונה של המסגרת או הספרייה, ולא של הקוד שלכם.
נקודות הכניסה למסגרת, כמו פעילויות, קטעים או שירותים, לא צריכות לכלול לוגיקה עסקית, ולכן בדיקת יחידה לא צריכה להיות בעדיפות גבוהה. בדיקות יחידה לפעילויות לא מועילות במיוחד, כי הן מכסות בעיקר את קוד המסגרת, והן דורשות הגדרה מורכבת יותר. בדיקות עם מכשירי מדידה, כמו בדיקות ממשק משתמש, יכולות לכלול את הכיתות האלה.
בדיקות ממשק משתמש
יש כמה סוגים של בדיקות ממשק משתמש שכדאי להשתמש בהם:
בדיקות ממשק משתמש במסך בודקות אינטראקציות קריטיות של משתמשים במסך אחד. הם מבצעים פעולות כמו לחיצה על לחצנים, הקלדה בטפסים ובדיקת מצבים גלויים. נקודת התחלה טובה היא ליצור סיווג בדיקה אחד לכל מסך.
בדיקות תהליך השימוש או בדיקות ניווט, שמכסות את המסלולים הנפוצים ביותר. הבדיקות האלה מדמות משתמש שנע דרך תהליך ניווט. אלה בדיקות פשוטות שיעזרו לכם לבדוק אם יש קריסות בזמן ריצה במהלך האיפוס.
בדיקות אחרות
יש בדיקות מיוחדות יותר, כמו בדיקות צילומי מסך, בדיקות ביצועים ובדיקות קוף. אפשר גם לסווג את הבדיקות לפי מטרה, כמו בדיקות רגרסיה, בדיקות נגישות ובדיקות תאימות.
מקורות מידע נוספים
כדי לבצע בדיקה בבידוד, לרוב צריך להחליף את יחסי התלות של הנושא שבבדיקה ביחסי תלות מזויפים או מדומים, שנקראים בדרך כלל 'עזרי בדיקה'. מידע נוסף זמין במאמר שימוש ב-test doubles ב-Android.
רוצים ללמוד איך יוצרים בדיקות יחידה ובדיקות ממשק משתמש? כדאי לעיין בcodelabs בנושא בדיקות.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[null,null,["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],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)."]]
