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

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

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

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

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

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

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

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

נושא

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

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

היקף

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

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

ארכיטקטורה שניתן לבדוק

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

ארכיטקטורה לא ניתנת לבדיקה יוצרת את התוצאות הבאות:

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

מידע נוסף על הנחיות הארכיטקטורה זמין במדריך לארכיטקטורת אפליקציות.

גישות לניתוק

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

שיטות נפוצות לניתוק כוללות:

  • לפצל אפליקציה לשכבות כמו 'תצוגה', 'דומיין' ו'נתונים'. אפשר גם לפצל אפליקציה למודולים, אחד לכל תכונה.
  • כדאי להימנע מהוספת לוגיקה לישויות שיש להן יחסי תלות גדולים, כמו פעילויות ומקטעים. אפשר להשתמש במחלקות האלה כנקודות כניסה ל-framework, ולהעביר לוגיקה של ממשק משתמש ולוג עסקי למקום אחר, כמו קומפוזבילי, ViewModel או שכבת דומיין.
  • הימנעו מיחסי תלות ישירים במסגרת בכיתות שמכילות לוגיקה עסקית. לדוגמה, אין להשתמש ב-Android Contexts ב-ViewModels.
  • החלפת יחסי התלות בקלות. לדוגמה, כדאי להשתמש בממשקים במקום בהטמעות קונקרטיות. משתמשים בהחדרת תלות גם אם לא משתמשים ב-framework של DI.

השלבים הבאים

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

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