יש ליישם בדיקות מארח Java Archive (JAR) כדי לספק כיסוי קוד מלא של התוכנה שלך. עקוב אחר ההוראות לבניית בדיקות יחידה מקומית . כתוב בדיקות יחידות קטנות כדי לאמת פונקציה ספציפית ותו לא.
דוגמא
קובץ ה-Blueprint הבא מספק דוגמה פשוטה לבדיקת מארח Hello World JAR להעתקה והתאמה לצרכים שלך: platform_testing/tests/example/jarhosttest/Android.bp
זה מתאים לקוד הבדיקה בפועל שנמצא בכתובת: platform_testing/tests/example/jarhosttest/test/android/test/example/helloworld/HelloWorldTest.java
תמונת מצב של קובץ Blueprint כלולה כאן לנוחות:
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 [options] <HelloWorldHostTest>
כדי לבנות את מודול הבדיקה שלך ואת כל התלות שלו.name: "HelloWorldHostTest",
ההגדרה
test_suites
הופכת את הבדיקה לניתנת לגילוי בקלות על ידי רתמת הבדיקה של Trade Federation. ניתן להוסיף כאן חבילות בדיקה נוספות, כגון CTS, כך שניתן יהיה לשתף את מבחן ה- JAR המארח.test_suites: ["general-tests"],
ההגדרה
static_libs
מורה למערכת הבנייה לשלב את התוכן של המודולים בעלי השם ב-APK שנוצר של המודול הנוכחי. המשמעות היא שכל מודול בעל שם צפוי לייצר קובץ.jar
. התוכן של המודול משמש לפתרון הפניות לנתיב לכיתה במהלך זמן ההידור ומשולב ב-APK שנוצר.static_libs: [ "junit", ],