כתיבת בדיקה ללא מכשיר בצד המארח ב-TF

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

בדף הזה מוסבר איך לכתוב בדיקה בצד המארח שלא דורשת מכשיר, למשל בדיקה שפועלת במכונה של Linux GCE. (פרטים על כתיבת בדיקה מבוססת-מארח שדורשת מכשיר זמינים במאמר כתיבה של בדיקה מבוססת-מארח באיחוד שירותי ה-Trade Federation).

סוגי בדיקות בצד המארח

אפשר להריץ כמה סוגים של בדיקות בצד המארח דרך Trade Federation‏ (TF).

בדיקות מקוריות (gtest)

יצירת בדיקות מותאמות (gtests) כדי לבדוק פלטפורמה. אם הבדיקה לא דורשת מכשיר, כדאי להריץ אותה במארח. כך הבדיקה תרוץ מהר יותר. כדי להגדיר בדיקות כאלה כך שיופעלו במארח בדיקה, משתמשים ב-TF runner‏ HostGTest.

זוהי דוגמה להגדרות אישיות לבדיקה של TradeFed:

<configuration description="Runs hello_world_test.">
    <option name="null-device" value="true" />
    <test class="com.android.tradefed.testtype.HostGTest" >
        <option name="module-name" value="hello_world_test" />
    </test>
</configuration>

הגדרות הבדיקה מפעילות בדיקת gtest (hello_world_test) במארח. אפשר ליצור באופן אוטומטי את קובץ התצורה לדוגמה של הבדיקה. אם לא נדרשת הגדרה או ניקוי מיוחדים לבדיקה, אפשר להשתמש ביצירה אוטומטית של הגדרות בדיקה כדי ליצור הגדרות בדיקה מתאימות ב-TF.

כדי להגדיר gtest בצד המארח ולהפעיל יצירה אוטומטית של הגדרות בדיקה, מגדירים את host_supported כ-true בקובץ Android.bp, כמו ב-hello_world_test.

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

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

בדיקות מארח של JAR‏ (Java), כמו JUnit, הן בדיקות שלא צריך להריץ במכשיר, והן מספקות כיסוי קוד של פרויקט Java. אפשר להגדיר בדיקות כאלה כך שיופעלו במארח בדיקה באמצעות ה-runner‏ HostTest.

הגדרות לדוגמה לבדיקה של TradeFed

<configuration description="Executes HelloWorldHostTest">
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="jar" value="HelloWorldHostTest.jar" />
    </test>
</configuration>

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

פרטים נוספים על כתיבת בדיקת מארח JAR מופיעים בדף בדיקות מארח JAR‏ (Java).

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

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

• זהו ה-runner שמוגדר כברירת מחדל לבדיקות יחידה של Robolectric ו-JUnit
• Tradefed תומך רק בבדיקות JUnit בסביבת הבידוד.
• יש תמיכה רק ביחסי תלות שמקושרים באופן סטטי. ספריות שתלויות בספריות אחרות שהוצהרו באמצעות lib לא נכללות ב-Classpath.
• הכלי לריצה בארגז חול רק מעביר את ה-shim runner ואת קובץ ה-jar של הבדיקה ל-classpath.
• יש עלות קבועה מסוימת לכל הרצה של בדיקה שמבוצעת באמצעות ה-Runner הזה.

הגדרה לדוגמה של בדיקת Tradefed (מופרדת)

<configuration description="Executes HelloWorldHostTest">
    <test class="com.android.tradefed.testtype.IsolatedHostTest" >
        <option name="jar" value="HelloWorldHostTest.jar" />
    </test>
</configuration>

דוגמה להגדרת Soong ליצירה אוטומטית

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

java_test_host {
    name: "HelloWorldHostTest",

    test_options: {
        unit_test: true,
    },

    test_suites: ["general-tests"],

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

    static_libs: [
        "junit",
    ],
}

בדיקות Robolectric

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

• האפשרות robolectric-resources מאפשרת להעביר ל-subprocess כמה אפשרויות שקושרות ל-Robolectric, וגם להוסיף את build העץ של android-all ל-classpath של ה-subprocess. שתי האפשרויות האחרות הן שיטות מומלצות, אבל האפשרות הזו חובה כדי להריץ בדיקות Robolectric.
• האפשרות java-folder מאפשרת לשנות את סביבת זמן הריצה של Java שבה משתמש תהליך המשנה. הדבר נחוץ כי ל-Robolectric יש העדפה לגרסאות Java מסוימות, שעשויות להיות שונות מ-JVM המועדף של מערכת המארח.
• האפשרות exclude-paths מאפשרת למפעיל תהליך המשנה להימנע כלל מעומס של מודולים מסוימים. האפשרות הזו שימושית כשקובץ JAR מגיע עם כיתות מיותרות שעלולות לגרום לשגיאות טעינה. java. היא החרגה נפוצה, כדי להימנע מהשלכת חריגות SecurityException.

הגדרה לדוגמה של Robolectric

<configuration description="Executes a Sample Robolectric Test">
    <option name="java-folder" value="prebuilts/jdk/jdk9/linux-x86/" />
    <option name="exclude-paths" value="java" />
    <option name="use-robolectric-resources" value="true" />
    <test class="com.android.tradefed.testtype.IsolatedHostTest">
        <option name="jar" value="RobolectricExampleTest.jar" />
    </test>
</configuration>

דוגמה להגדרת Soong ליצירה אוטומטית של Robolectric

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

android_robolectric_test {
    name: "HelloWorldRoboTest",
    srcs: [
        "src/**/*.java",
    ],

    // Include the testing libraries
    static_libs: [
        "mockito-robolectric-prebuilt",
        "platform-test-annotations",
        "testng",
        "truth-prebuilt",
    ],

    instrumentation_for: "HelloWorldApp",
}

בדיקת Python

אם הלוגיקה של הבדיקה נכתבת ב-Python, משתמשים בסוג build‏ python_test_host כדי ליצור קובץ par שאפשר להריץ באמצעות TF PythonBinaryHostTest.

הגדרות לדוגמה לבדיקה של TradeFed

<configuration description="Config to run atest unittests">
    <test class="com.android.tradefed.testtype.python.PythonBinaryHostTest" >
        <option name="par-file-name" value="atest_unittests" />
        <option name="test-timeout" value="2m" />
    </test>
</configuration>

הגדרת חבילת הבדיקה

כדי ש-TF תהיה גישה לבדיקה בצד המארח לגרסה נתונה של build, צריך להגדיר את הערך `test_suites` של מודול הבדיקה לערך `general-tests`:

test_suites: ["general-tests"],

בהגדרה הזו, הבדיקה נארזת ל-general-tests.zip ביעד test_suites.