בדיקות של מארחי JAR

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

דוגמה

קובץ ה-Blueprint הבא מספק דוגמה פשוטה לבדיקת מארח JAR של Hello World שאפשר להעתיק ולהתאים לצרכים שלכם: platform_testing/tests/example/jarhosttest/Android.bp

הקוד הזה תואם לקוד הבדיקה בפועל שנמצא במיקום הבא: platform_testing/tests/example/jarhosttest/test/android/test/example/helloworld/HelloWorldTest.java

לנוחותכם, הוספנו כאן תמונת מצב של קובץ התוכנית:

java_test_host {
    name: "HelloWorldHostTest",

    test_suites: ["general-tests"],

    srcs: ["test/**/*.java"],

    static_libs: [
        "junit",
        "mockito",
    ],
}

ההצהרה java_test_host בתחילת הקובץ מציינת שמדובר בבדיקת מארח JAR. דוגמה לשימוש בו אפשר לראות בכתובת: frameworks/base/tools/powermodel/Android.bp

הגדרות

בהמשך מופיעים הסברים על ההגדרות הבאות:

• ההגדרה name נדרשת כשמציינים את סוג המודול java_test_host (בתחילת הבלוק). ההגדרה הזו נותנת שם למודול, וקובץ ה-JAR שמתקבל מקבל את אותו שם עם הסיומת .jar. בדוגמה שלמטה,קובץ ה-JAR של הבדיקה נקרא HelloWorldHostTest.jar. בנוסף, ההגדרה הזו מגדירה גם שם של יעד make למודול, כך שאפשר להשתמש ב-make [options] <HelloWorldHostTest> כדי ליצור את מודול הבדיקה ואת כל התלות שלו.

  name: "HelloWorldHostTest",
  

• ההגדרה test_suites מאפשרת למערכת Trade Federation למצוא את הבדיקה בקלות. אפשר להוסיף לכאן חבילות בדיקה אחרות, כמו CTS, כדי שניתן יהיה לשתף את בדיקת המארח JAR.

  test_suites: ["general-tests"],
  

• ההגדרה static_libs מורה למערכת ה-build לשלב את התוכן של המודולים שצוינו ב-APK שמתקבל של המודול הנוכחי. כלומר, כל מודול עם שם אמור ליצור קובץ .jar. התוכן של המודול משמש לפתרון הפניות לנתיב המחלקה במהלך ההידור, והוא משולב בקובץ ה-APK שמתקבל.

  static_libs: [
      "junit",
  ],