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

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

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

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

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

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

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

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

נושא

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

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

היקף

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

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

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

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

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

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

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

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

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

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

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

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

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

גישות להפרדה

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

שיטות נפוצות להפרדה כוללות:

  • לפצל אפליקציה לשכבות כמו Presentation,‏ Domain ו-Data. אפשר גם לפצל אפליקציה למודולים, מודול אחד לכל תכונה.
  • מומלץ להימנע מהוספת לוגיקה לישויות שיש להן יחסי תלות גדולים, כמו פעילויות וקטעים. השתמשו במחלקות האלה כנקודות כניסה למסגרת והעבירו את ממשק המשתמש והלוגיקה העסקית למקום אחר, כמו Composable,‏ ViewModel או שכבת דומיין.
  • הימנעו מתלויות ישירות במסגרת במחלקות שמכילות לוגיקה עסקית. לדוגמה, אל תשתמשו בהקשרים של Android ב-ViewModels.
  • חשוב שיהיה קל להחליף את יחסי התלות. לדוגמה, השתמשו בממשקים במקום בהטמעות קונקרטיות. השתמשו בהזרקת תלות גם אם אתם לא משתמשים במסגרת DI.

השלבים הבאים

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

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