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

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

קוד מקור

לדוגמה, אפשר לעיין במאמר Hello World GTest.

קוד המקור של הדוגמה הזו מופיע כאן עם הערות:

#include <gtest/gtest.h>

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

#include <stdio.h>

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

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

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

מידע נוסף על כתיבת בדיקות באמצעות GTest זמין במסמכי התיעוד של GTest.

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

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

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

כדי להשתמש ב-Trade Federation במקום זאת, צריך לכתוב קובץ הגדרות בדיקה עבור פלטפורמת הבדיקה של Android, ‏ Trade Federation.

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

פיתוח ובדיקה באופן מקומי

בתרחישים הנפוצים ביותר, כדאי להשתמש ב-Atest.

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