הוספת דוגמה חדשה למבחן יליד

אם אתה חדש בפיתוח פלטפורמת אנדרואיד, ייתכן שתמצא דוגמה מלאה זו של הוספת מבחן מותג חדש מאפס שימושי להדגמת זרימת העבודה האופיינית הכרוכה בכך. בנוסף, אם אתה לא מכיר אף אחד עם מסגרת 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 ספריית שינוי גריט המדגם. הפרקים שלהלן יסבירו בפרטים נוספים של כל קובץ.

קוד מקור

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

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

#include <gtest/gtest.h>

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

#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 מספיקה. ראה תצורת בדיקה פשוטה לפרטים.

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

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

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

לבנות ולבדוק מקומית

עבור המקרים רוב השימוש הנפוץ, להעסיק atest .

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