הוספת בדיקות 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.

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