אם אתם מתחילים בפיתוח בפלטפורמת 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>
קובץ ה include של הכותרת ל-GTest. כדי לפתור את התלות בקובץ ההכללה, משתמשים ב-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 Test Harness, Trade Federation.
בהגדרת הבדיקה אפשר לציין אפשרויות מיוחדות להגדרת המכשיר וארגומנטים שמוגדרים כברירת מחדל כדי לספק את הכיתה של הבדיקה.
פיתוח ובדיקה באופן מקומי
בתרחישים הנפוצים ביותר לדוגמה, כדאי להשתמש ב-Atest.
במקרים מורכבים יותר שדורשים התאמה אישית משמעותית יותר, פועלים לפי הוראות המדידה.