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

הגדרת אסטרטגיית בדיקה

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

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

בדיקות לא תקינות

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

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

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

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

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

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

מתקרב לפענוח

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

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

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

השלבים הבאים

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

לחלופין, אם רוצים ליצור את הבדיקה הראשונה וללמוד ממנה, לקרוא את Testing Codelabs.