יסודות הבדיקה של אפליקציות ל-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()))

ממשק המשתמש של כתיבת הודעות

// 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)

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

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

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

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

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

גישות להפרדה

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

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

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

השלבים הבאים

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

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