הוספת בדיקות Google חדשות (GTests)

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

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

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

קוד מקור

עיין ב- Hello World GTest לדוגמא.

קוד המקור של אותה דוגמה מובא כאן:

#include <gtest/gtest.h>

קובץ כותרת כולל עבור GTest. התלות בקובץ include נפתרת אוטומטית באמצעות BUILD_NATIVE_TEST בקובץ make.

#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, עיין בתיעוד GTest

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

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

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

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

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

בנה ובדוק באופן מקומי

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

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