ספקים של תוכן לבדיקה

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

יצירת בדיקות שילוב לספקי תוכן

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

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

צריך לכתוב את בדיקת השילוב ככיתת בדיקה של JUnit 4. מידע נוסף על יצירת כיתות בדיקה של JUnit 4 ושימוש בטענות נכונות (assertions) של JUnit 4, ראו יצירת כיתות שיעור בדיקת יחידה מקומית.

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

  1. יצירת כיתת הבדיקה ככיתת משנה של ProviderTestCase2.
  2. מציינים את המחלקה AndroidJUnitRunner ש-AndroidX Test מספק כברירת מחדל להרצת הבדיקה.
  3. מגדירים את האובייקט Context מהמחלקה ApplicationProvider. לצפייה כדוגמה.

Kotlin


@Throws(Exception::class)
override fun setUp() {
  super.setUp()
  context = ApplicationProvider.getApplicationContext<Context>()
}

Java


@Override
protected void setUp() throws Exception {
  super.setUp();
  setContext(ApplicationProvider.getApplicationContext());
}

איך פלטפורמת ProviderTestCase2 פועלת

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

אתחול

האתחול מתבצע ב-constructor של ProviderTestCase2, שמחלקות המשנה קוראות ל-constructor שלהם. ProviderTestCase2 constructor יוצר אובייקט IsolatedContext שמאפשר לקובץ אך "מאתר" אינטראקציות אחרות עם מערכת Android." הפעולות של הקבצים ומסד הנתונים עצמן מתבצעות בספרייה מקומי במכשיר או באמולטור, ויש לו קידומת מיוחדת.

לאחר מכן ה-constructor יוצר MockContentResolver שישמש כמקודד לצורך הבדיקה.

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

מריצים בדיקות שילוב לספקי תוכן באותו אופן כמו בדיקות יחידה (unit testing).

מה צריך לבדוק

הנה כמה הנחיות ספציפיות לבדיקת ספקי תוכן.

  • בדיקה באמצעות שיטות של מקודד: אף על פי שאפשר ליצור מופע של ספק אובייקט ב-ProviderTestCase2, צריך תמיד לבדוק עם אובייקט מקודד באמצעות את ה-URI המתאים. כך תבטיחו שהספק נבדק על ידי לבצע את אותה אינטראקציה כמו באפליקציה רגילה.
  • לבדוק ספק ציבורי כחוזה: אם אתם מתכוונים שהספק שלכם יהיה ציבורי וזמין לאפליקציות אחרות, עליכם לבדוק אותו כחוזה. הנה כמה דוגמאות:
    • בודקים בעזרת קבועים שהספק חושף באופן ציבורי. לדוגמה, תראו קבועים שמפנים לשמות עמודות באחת מטבלאות הנתונים של הספק. הערכים האלה צריכים להיות קבועים באופן ציבורי על ידי הספק.
    • בדיקת כל מזהי ה-URI שהספק שלכם מציע. הספק שלך עשוי להציע מזהי URI, שכל אחד מהם מפנה להיבט אחר של הנתונים.
    • יש לבדוק מזהי URI לא חוקיים. בדיקות היחידה שלך צריכות להתקשר בכוונה לספק עם URI לא חוקי ולחפש שגיאות. תכנון נכון של ספק הוא IllegalArgumentException עבור מזהי URI לא חוקיים.
  • בודקים את האינטראקציות הרגילות של הספקים: רוב הספקים מציעים שישה הרשאות גישה שיטות: query(), insert(), delete(), update(), getType() ו onCreate(). הבדיקות אמורות לוודא שכל השיטות האלה פועלות.
  • בודקים את הלוגיקה העסקית: אם ספק התוכן מטמיע לוגיקה עסקית, עבורך לבדוק אותו. הלוגיקה העסקית כוללת טיפול בערכים לא חוקיים, התנהלות פיננסית או חישובים אריתמטיים, ביטול או שילוב של כפילויות.