גוגל מחויבת לקדם הון גזעי עבור קהילות שחורות. תראה איך.
דף זה תורגם על ידי Cloud Translation API.
Switch to English

הוספת דוגמא חדשה לבחינת הילידים

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

מדריך זה משתמש במבחן הבא כדי לשמש דוגמה:

שלום מבחן הילידים העולמי

מומלץ לדפדף בקוד תחילה כדי להתרשם גס לפני שתמשיך.

החלטה על מיקום מקור

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

בהנחה במיקום הבסיס עבור מקור הרכיב שלך נמצאת <component source root> , ולרובם יש רכיבים src ו tests תיקיות מתחתיה, וכמה קבצים נוספים כגון Android.mk (או התפרק נוספים .bp קבצים).

מכיוון שאתה מוסיף מבחן חדש לגמרי, סביר להניח שתצטרך ליצור את ספריית tests לצד רכיב ה- src שלך, ולאכלס אותה בתוכן.

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

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

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- src (test source)
          \-- foo_test.cpp
          \-- ...
 

והנה מתאר ספרייה טיפוסי לרכיבים עם ספריות מקור רבות לבדיקה:

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- testFoo (sub test source root)
      |   \-- Android.bp (sub test makefile)
      |   \-- src (sub test source)
      |       \-- test_foo.cpp
      |       \-- ...
      \-- testBar
      |   \-- Android.bp
      |   \-- src
      |       \-- test_bar.cpp
      |       \-- ...
      \-- ...
 

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

קוד מקור

ראה דוגמא למבחן הילידים העולמי .

קוד המקור המוערך מופיע להלן:

 #include <gtest/gtest.h>
 

קובץ הכותרת כולל עבור gtest. שים לב שתלות הקבצים כוללת נפתרת אוטומטית על ידי שימוש ב- BUILD_NATIVE_TEST בתכנית ה- BUILD_NATIVE_TEST

 #include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}
 

gtests נכתבים באמצעות מאקרו TEST : הפרמטר הראשון הוא שם מקרה הבדיקה, והשני הוא שם הבדיקה; יחד עם שם בינארי לבדיקה, הם יוצרים את ההיררכיה שלהלן כאשר הם מדמיינים בלוח המחוונים של התוצאות:

 <test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...
 

למידע נוסף על כתיבת בדיקות עם gtest, עיין בתיעוד שלה:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

קובץ תצורה פשוט

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

קובץ תצורה מורכב

כדי להשתמש במקום זאת ב- Federation Federation, כתוב קובץ תצורת מבחן לרתמת הבדיקה של אנדרואיד, Federation Federation .

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

בנה ובחן מקומי

עבור מקרי השימוש הנפוצים ביותר, השתמש ב- Atest .

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