בדיקה משורת הפקודה

במסמך הזה נסביר איך להריץ בדיקות ישירות משורת הפקודה. הזה מבוסס על ההנחה שאתם כבר יודעים איך ליצור אפליקציה ל-Android לכתוב בדיקות לאפליקציה. לקבלת מידע נוסף על בניית בדיקות עבור תוכלו להיעזר במאמר בדיקת אפליקציות ב-Android.

כשבונים את האפליקציה באמצעות מערכת ה-build של Gradle, התכונה Android Gradle הפלאגין מאפשר להריץ בדיקות מ-Gradle את הפרויקט באמצעות שורת הפקודה. לשליטה פרטנית יותר, אפשר להריץ את הבדיקות דרך גשר לניפוי באגים ב-Android (adb). הדבר יכול להיות שימושי כאשר מריצים בדיקות אינטגרציה רציפה (CI).

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

הרצת בדיקות באמצעות Gradle

הפלאגין Android Gradle מאפשר לך להריץ בדיקות מפרויקט Gradle באמצעות בשורת הפקודה.

הטבלה הבאה מסכמת את האופן שבו מריצים בדיקות באמצעות Gradle:

טבלה 1. דרכים שונות להריץ בדיקות גרדל

סוג של בדיקת יחידה	הפקודה להרצה	מיקום תוצאת הבדיקה
בדיקת יחידה מקומית	מריצים את המשימה test: ./gradlew test	קובצי תוצאות בדיקת HTML: path_to_your_project/module_name/build/reports/tests/ קובצי תוצאות בדיקת XML: path_to_your_project/module_name/build/test-results/
בדיקת יחידה אינסטרומנטלית	מריצים את המשימה connectedAndroidTest: ./gradlew connectedAndroidTest	קובצי תוצאות בדיקת HTML: path_to_your_project/module_name/build/reports/androidTests/connected/ קובצי תוצאות בדיקת XML: path_to_your_project/module_name/build/outputs/androidTest-results/connected/

תמיכה ב-Gradle לקיצורים של שמות המשימות. לדוגמה, כדי להתחיל את המשימה connectedAndroidTest, הזנת הפקודה הבאה:

./gradlew cAT

אפשר גם להריץ את משימות Gradle check ו-connectedCheck. האלה להריץ את הבדיקות המקומיות או האינסטרומנטליות, בהתאמה, כוללים בדיקות אחרות שנוספו על ידי יישומי פלאגין אחרים של Gradle.

הרצת בדיקות במודול

המשימות test ו-connectedAndroidTest מריצים בדיקות על כל מודול פרויקט. כדי להריץ בדיקות במודול ספציפי, הוספת קידומת למשימה test או connectedAndroidTest עם שם המודול ו נקודתיים (:). לדוגמה, הפקודה הבאה מפעילה בדיקות אינסטרומנטליות עבור המודול mylibrary:

./gradlew mylibrary:connectedAndroidTest

הרצת בדיקות על וריאנט build

המשימה test ו-connectedAndroidTest מריצה בדיקות על כל אחת מהן ליצור וריאנט בפרויקט. אפשר לטרגט לווריאנט build ספציפי באמצעות התחביר הבא:

• לבדיקות יחידה מקומיות:

  ./gradlew testVariantNameUnitTest

• לבדיקות אינסטרומנטליות:

  ./gradlew connectedVariantNameAndroidTest

הערה: כדי להגביל עוד יותר את הבדיקות שמריצים, אפשר לטרגט ניסוי ספציפי של גרסת ה-build במודול ספציפי. לדוגמה, אפשר להשתמש ב-./gradlew mylibrary:connectedVariantNameUnitTest כדי להריץ את כל בדיקות היחידות עבור הווריאנט VariantName בתוך mylibrary .

להריץ שיטות בדיקה או כיתות ספציפיות לבדיקה

כשמריצים בדיקות יחידה מקומיות, Gradle מאפשרת לך לטרגט בדיקות ספציפיות באמצעות הדגל --tests. לדוגמה, הפקודה הבאה מפעילה רק sampleTestMethod בדיקות לווריאנט ה-build שצוין. מידע נוסף על באמצעות הדגל --tests, קריאת התיעוד של Gradle על סינון בדיקה.

./gradlew testVariantNameUnitTest --tests '*.sampleTestMethod'

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

הרצת בדיקות עם adb

כשמריצים בדיקות משורת הפקודה באמצעות Android Debug Bridge (adb), יש עוד אפשרויות והיא בוחרת את הבדיקות שמריצים מאשר בכל שיטה אחרת. אפשר לבחור קמפיינים ספציפיים שיטות בדיקה, סינון בדיקות לפי הערה מותאמת אישית או ציון בדיקות אפשרויות. מכיוון שהרצת הבדיקה נשלטת במלואה משורת הפקודה, יכולים להתאים אישית את הבדיקה עם סקריפטים של מעטפת בדרכים שונות.

כדי להריץ בדיקה משורת הפקודה, מריצים את adb shell כדי להפעיל את שורת הפקודה המעטפת במכשיר או באמולטור שלכם. בתוך המעטפת אפשר לבצע פעולות מנהל פעילות באמצעות הפקודה am ולהשתמש בפקודת המשנה instrument כדי להריץ את הבדיקות.

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

כדי להריץ בדיקה באמצעות am instrument:

1. פיתוח או יצירה מחדש של האפליקציה הראשית, חבילת בדיקה.
2. מתקינים את חבילת הבדיקה ואת האפליקציה הראשית קובצי חבילת Android של האפליקציה (קובצי APK) למכשיר Android הנוכחי או אמולטור.

3. בשורת הפקודה, מזינים:

   adb shell am instrument -w <test_package_name>/<runner_class>
   

   כאשר <test_package_name> הוא שם החבילה ל-Android של הבדיקה ו-<runner_class> הוא השם של מחלקת ההרצה במבחן של Android. שבהם השתמשת. שם החבילה של Android הוא הערך של רכיב המניפסט המאפיין package בקובץ המניפסט של חבילת הבדיקה (AndroidManifest.xml).

   בדרך כלל, השיעור של הרצת הבדיקה של Android הוא AndroidJUnitRunner:

   adb shell am instrument -w com.android.example/androidx.test.runner.AndroidJUnitRunner
   

תוצאות הבדיקה שלך מופיעות בSTDOUT.

דגלים של כלי נגינה

כדי למצוא רשימה של כל הדגלים שבהם צריך להשתמש בפקודה am instrument: להריץ את adb shell am help. פירטנו כאן כמה מהסימונים החשובים הטבלה הבאה:

טבלה 2. חשוב am instrument דגלים

סימון	ערך	תיאור
-w	(ללא)	המערכת מאלצת את am instrument להמתין עד למדידה מסתיים לפני שהוא מסיים את עצמו. כך נשמרת היא פתוחה עד שהבדיקות יסתיימו. הסימון הזה נדרש כדי לראות את תוצאות הבדיקות.
-r	(ללא)	הפלט מוביל לפורמט גולמי. השתמשו בדגל הזה כשרוצים לאסוף מדדי ביצועים כך שהפורמט שלהם לא תוצאות הבדיקה. הדגל הזה מיועד לשימוש עם הדגל -e perf true (מתועד ב: am instrument options)
-e	<test_options>	מספקת אפשרויות בדיקה בתור צמדי מפתח-ערך. הכלי am instrument מעביר את הפריטים האלה סיווג אינסטרומנטציה באמצעות onCreate() . ניתן לציין כמה מופעים של -e <test_options> המפתחות והערכים הם שמתוארים am instrument options אפשר להשתמש רק בצמדי מפתח/ערך האלה AndroidJUnitRunner או באמצעות InstrumentationTestRunner ואת מחלקות המשנה שלו. לשימוש בהם בכל כיתה אחרת אין השפעה.
--no-hidden-api-checks	(ללא)	ההגדרה משביתה את הגבלות השימוש בממשקי API מוסתרים. לקבלת מידע נוסף על ממשקי API נסתרים ואיך הם יכולים להשפיע אפליקציה, קריאה הגבלות על ממשקים שאינם SDK.

אפשרויות כלי נגינה

הכלי am instrument מעביר את אפשרויות הבדיקה אל AndroidJUnitRunner או InstrumentationTestRunner בצורת צמדי מפתח-ערך, שמשתמשים בדגל -e, עם התחביר הבא:

-e <key> <value>

חלק מהמפתחות מקבלים ערכים מרובים. אם מציינים כמה ערכים בקובץ ה-Cookie רשימה מופרדת בפסיקים. לדוגמה, ההפעלה של AndroidJUnitRunner מספק כמה ערכים למפתח package:

adb shell am instrument -w -e package com.android.test.package1,com.android.test.package2 \
> com.android.test/androidx.test.runner.AndroidJUnitRunner

הטבלה הבאה מפרטת את צמדי המפתח/ערך שבהם אפשר להשתמש עם מפעיל הבדיקה:

טבלה 3. -e סימון צמדי מפתח/ערך לשימוש עם משחק הבדיקה

מפתח	ערך	תיאור
package	<Java_package_name>	שם החבילה המלאה של Java של אחד חבילות באפליקציה לבדיקה. כל מחלקה של מקרה בדיקה שמשתמשת בערך הזה שם החבילה מופעל. שימו לב שזוהי לא שם חבילה של Android; לחבילת בדיקה יש שם החבילה של Android, אבל יכולות להיות בו כמה חבילות Java.
class	<class_name>	שם המחלקה המלאה ב-Java של אחד ממקרי הבדיקה הסוגים. רק המחלקה של תרחיש הניסיון הזו מבוצעת.
	<class_name>#method name	שם מחלקה של מקרה בדיקה ואחת מהשיטות שלו. רק שה-method הזה מופעל. חשוב לשים לב לסימן הגיבוב (#) בין הכיתה ואת שם ה-method.
func	true	מריץ את כל כיתות המבחן InstrumentationTestCase
unit	true	מריץ את כל כיתות הבדיקה שלא נמשכות InstrumentationTestCase או PerformanceTestCase
size	[small | medium | large]	מריצה שיטת בדיקה עם הערות לפי גודל. ההערות הן @SmallTest, @MediumTest וגם @LargeTest.
perf	true	מריץ את כל מחלקות הבדיקה שמטמיעות PerformanceTestCase כשמשתמשים באפשרות הזו, צריך לציין את הדגל -r עבור am instrument כדי שהפלט יישמר בפורמט גולמי ולא נשנה את הפורמט שלהן כתוצאות בדיקה.
debug	true	מריצה בדיקות במצב ניפוי באגים.
log	true	טוענת ורושמת את כל הבדיקות שצוינו, אבל לא מריצה אותן. הבדיקה מופיע מידע ב-STDOUT. שימוש בנתון הזה לאימות שילובים של מסננים אחרים ומפרטי בדיקה.
emma	true	מפעיל ניתוח כיסוי של קוד EMMA וכותב את הפלט /data/<app_package>/coverage.ec במכשיר. שפת תרגום לשנות את מיקום הקובץ ולהשתמש במקש coverageFile כפי שמתואר בערך הבא. הערה: לאפשרות הזו נדרש אמצעי EMMA של אפליקציית הבדיקה, שאפשר ליצור באמצעות יעד אחד (coverage).
coverageFile	<filename>	ביטול של מיקום ברירת המחדל של קובץ הכיסוי של EMMA במכשיר. יש לציין את הערך הזה כנתיב ושם קובץ בפורמט UNIX. שם ברירת המחדל של הקובץ מתואר ברשומה של מקש emma.

כשמשתמשים בדגל -e, חשוב לשים לב לנקודות הבאות:

• הפעלה של am instrument onCreate(Bundle) עם Bundle שמכיל את ערך המפתח זוגות של מילים.
• המפתח package מקבל עדיפות על פני המפתח class. אם תציינו ולאחר מכן לציין בנפרד מחלקה בתוך החבילה, Android מריץ את כל הבדיקות בחבילה ומתעלמת ממפתח המחלקה.
• המפתח func והמפתח unit הם בלעדיים.

דוגמאות לשימוש

בקטעים הבאים מובאות דוגמאות לשימוש ב-am instrument כדי להריץ בדיקות. הם מבוססים על המבנה הבא:

• שם החבילה של חבילת הבדיקה ל-Android הוא com.android.demo.app.tests.
• שתי שיעורי בדיקה לפי אינסטרומנטציה:
  • TestClass1, שמכיל את שיטת הבדיקה testMethod1.
  • TestClass2, שמכיל את שיטות הבדיקה testMethod2 ו-testMethod3.
• משחק הבדיקה הוא AndroidJUnitRunner

הרצת חבילת הבדיקה כולה

כדי להריץ את כל כיתות הבדיקה בחבילת הבחינה, מזינים:

adb shell am instrument -w com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

הרצת כל הבדיקות במחלקה של מקרי בדיקה

כדי להריץ את כל הבדיקות בכיתה TestClass1, צריך להזין:

adb shell am instrument -w  \
> -e class com.android.demo.app.tests.TestClass1 \
> com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

בחירת קבוצת משנה של בדיקות

כדי להריץ את כל הבדיקות במחלקה TestClass1 ובשיטה testMethod3 ב-TestClass2, מזינים:

adb shell am instrument -w \
> -e class com.android.demo.app.tests.TestClass1,com.android.demo.app.tests.TestClass2#testMethod3 \
> com.android.demo.app.tests/androidx.test.runner.AndroidJUnitRunner

תרחישים נוספים לדוגמה זמינים AndroidJUnitRunner הפניית API.