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

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

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

בתרחישי השימוש הנפוצים ביותר, אישור.

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