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