יסודות הבדיקה של אפליקציות ל-Android

בדף הזה מפורטות העקרונות הבסיסיים לבדיקת אפליקציות ל-Android, כולל השיטות המומלצות המרכזיות והיתרונות שלהן.

היתרונות של בדיקה

בדיקה היא חלק בלתי נפרד מתהליך פיתוח האפליקציה. הרצת בדיקות מול האפליקציה באופן עקבי תאפשר לכם לוודא את הנכונות, ההתנהגות הפונקציונלית ונוחות השימוש של האפליקציה לפני שאתם מפרסמים אותה באופן ציבורי.

ניתן לבדוק את האפליקציה באופן ידני על ידי ניווט דרכה. אפשר להשתמש במכשירים ובמכונות וירטואליות שונים, לשנות את שפת המערכת ולנסות ליצור כל שגיאה של משתמש או לעבור בכל תהליך של משתמש.

עם זאת, קשה להתאים בדיקה ידנית למספרים גדולים של משתמשים, וקל מאוד להתעלם מנסיגות בהתנהגות האפליקציה. בדיקה אוטומטית כוללת שימוש בכלים שמבצעים בדיקות בשבילכם. הבדיקה הזו מהירה יותר, אפשר לחזור עליה בקלות רבה יותר, ובדרך כלל היא מספקת משוב פרקטי יותר לגבי האפליקציה בשלב מוקדם יותר בתהליך הפיתוח.

סוגי הבדיקות ב-Android

אפליקציות לנייד הן מורכבות ויכולות לפעול היטב בסביבות רבות. לכן, יש סוגים רבים של בדיקות.

נושא

לדוגמה, יש סוגים שונים של בחינות בהתאם לנושא:

• בדיקה פונקציונליות: האם האפליקציה שלי עושה את מה שהיא אמורה לעשות?
• בדיקת ביצועים: האם היא מתבצעת במהירות וביעילות?
• בדיקת נגישות: האם האתר פועל היטב עם שירותי נגישות?
• בדיקות תאימות: האם הקוד פועל היטב בכל מכשיר ובכל רמת API?

היקף

הבדיקות משתנות גם בהתאם לגודל או למידת הבידוד:

• בדיקות יחידה או בדיקות קטנות מאמתות רק חלק קטן מאוד מהאפליקציה, כמו שיטה או כיתה.
• בדיקות מקצה לקצה או בדיקות גדולות מאמתות חלקים גדולים יותר באפליקציה בו-זמנית, כמו מסך שלם או תהליך משתמש.
• בדיקות ברמה בינונית נמצאות באמצע, ובהן בודקים את האינטגרציה בין שתי יחידות או יותר.

יש דרכים רבות לסיווג בדיקות. עם זאת, ההבדל החשוב ביותר למפתחי אפליקציות הוא המיקום שבו מתבצעות הבדיקות.

בדיקות עם כלי למדידת ביצועים לעומת בדיקות מקומיות

אפשר להריץ בדיקות במכשיר Android או במחשב אחר:

• בדיקות עם מכשירי מדידה מריצים במכשיר Android, פיזי או ממולא. האפליקציה נוצרת ומתקנת לצד אפליקציית בדיקה שמחדירה פקודות וקוראת את המצב. בדיקות עם מכשירי מדידה הן בדרך כלל בדיקות של ממשק משתמש, שבהן מריצים אפליקציה ואז מבצעים איתה אינטראקציה.
• בדיקות מקומיות פועלות במחשב הפיתוח או בשרת, ולכן הן נקראות גם בדיקות בצד המארח. בדרך כלל הן קטנות ומהירות, ומבודדות את הנושא שבבדיקה משאר האפליקציה.

לא כל בדיקות היחידה הן מקומיות, ולא כל הבדיקות מקצה לקצה פועלות במכשיר. לדוגמה:

• בדיקה מקומית גדולה: אפשר להשתמש בסימולטור של 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()))

// 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 או לשכבת הדומיין.
• הימנעו מתלות ישירה של framework במחלקות שיש בהן לוגיקה עסקית. לדוגמה, אין להשתמש בהקשר של Android ב-ViewModels.
• החלפת יחסי התלות בקלות. לדוגמה, כדאי להשתמש בממשקים במקום בהטמעות קונקרטיות. כדאי להשתמש בהזרקת יחסי תלות גם אם לא משתמשים במסגרת DI.

השלבים הבאים

עכשיו כשאתם יודעים למה כדאי לבצע בדיקות ואילו שני סוגים עיקריים של בדיקות יש, תוכלו לקרוא את המאמר מה כדאי לבדוק או לקבל מידע על אסטרטגיות בדיקה.

לחלופין, אם אתם רוצים ליצור את הבדיקה הראשונה שלכם וללמוד תוך כדי עשייה, תוכלו להיעזר בcodelabs בנושא בדיקות.