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

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

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

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

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

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

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

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

נושא

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

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

היקף

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

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

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

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

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

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

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

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

השלבים הבאים

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

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