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