בדיקת קוד של פלטפורמה באמצעות atest

‫Android Studio for Platform‏ (ASfP) משולב עם atest ועם מודולי בדיקה של Soong, כך שאתם יכולים להריץ ולנפות באגים בבדיקות פלטפורמה במחשב המארח של Linux, במכשיר מחובר או במכשיר וירטואלי של Cuttlefish מתוך סביבת הפיתוח המשולבת (IDE).

דרישות מוקדמות

• פותחים פרויקט ASfP שהוגדר עם תשלום AOSP ויעד lunch.
• לצורך בדיקות מכשירים, מחברים מכשיר פיזי או מפעילים מכשיר וירטואלי של Cuttlefish עם גרסת build תואמת.

הרצה וניפוי באגים של בדיקות

אפשר להפעיל בדיקות של פלטפורמות וסשנים של ניפוי באגים מכמה מקומות ב-ASfP:

• Android.bp בדיקת יעדים: פותחים קובץ Android.bp ולוחצים על Run (הפעלה) בשוליים לצד מודול בדיקה כלשהו (*_test או *_test_host):
  • ‫Run: זמין לכל סוגי מודולי הבדיקה של Soong ‏ (android_test, java_test_host,‏ cc_test,‏ rust_test,‏ python_test,‏ sh_test ו-android_robolectric_test).
  • ‫Debug: זמין למודולים android_test (מצורפים עם מאתר הבאגים של Java באמצעות atest --wait-for-debugger) ולמודולים של בדיקות C++‎ או Rust (‏cc_test,‏ cc_test_host,‏ rust_test ו-rust_test_host, מופעלים במאתר הבאגים המובנה LLDB של ASfP).
• סמלים בשולי קובץ המקור: לוחצים על הפעלה לצד מחלקת בדיקה או @Testשיטה בקוד המקור כדי להפעיל או לנפות באגים בבדיקה הספציפית הזו.
• תפריט הקשר של לחיצה ימנית: לוחצים לחיצה ימנית על קובץ בדיקה, מחלקה, שיטה או מודול Android.bp ובוחרים באפשרות הפעלה או ניפוי באגים.
• סוכן מובנה (AI ב-Android Studio): בחלון הכלים Agent, הסוכן המובנה יכול להריץ atest יעדים כדי לאמת שינויים אחרי עריכת קוד.
• טרמינל משולב: פותחים את תצוגה > חלונות של הכלים > טרמינל כדי להריץ פקודות atest ישירות.

הגדרה חכמה של בדיקות וניפוי באגים

כשמפעילים בדיקה מהשוליים או מתפריט ההקשר, ASfP יוצרת ומגדירה הפעלה של Soong Test באמצעות גרף המודולים Android.bp.

ניפוי באגים android_test ביעדי Java ו-Kotlin

לוחצים על סמל השוליים לצד מודול android_test ב-Android.bp, או לצד מחלקה או שיטה של Java או Kotlin JUnit @Test, ואז בוחרים באפשרות Debug '<TestName>'‎. משוליים של קובץ מקור, ASfP בוחר את מודול android_test הסגירה הקרוב ביותר שsrcsכולל את הקובץ ונותן שם להגדרה <module>, <module>:<SimpleClass> או <module>:<SimpleClass>#<method>.

‫ASfP מריץ את atest עם --wait-for-debugger, קורא את מאפיין היעד package מהמודול AndroidManifest.xml, מחכה לתהליך הזה במכשיר המחובר ומצרף את מאתר הבאגים של Java.

ניפוי באגים ביעדים cc_test ו-rust_test ב-LLDB

כדי לנפות באגים במודול בדיקה ב-C++ או ב-Rust (cc_test, ‏ cc_test_host, ‏ rust_test או rust_test_host), לוחצים על הסמל Android.bp בסרגל הצד ובוחרים באפשרות Debug '<TestName>'‎. ‏ASfP מפעיל את קובץ ההפעלה של הבדיקה שקומפל תחת מנפה הבאגים LLDB המובנה שלו, במקום להפעיל אותו דרך atest.

הגדרת ההרצה של בדיקת Soong

פותחים את Run > Edit Configurations (הפעלה > עריכת הגדרות) ובוחרים הגדרה של Soong Test כדי להתאים אישית את האופן שבו הבדיקות נוצרות, נפרסות ומופעלות:

• השלמה אוטומטית של מודולים וניווט Android.bp: השלמה אוטומטית של השדה Module ממודולי בדיקה של Soong באינדקס בפרויקט. לוחצים על Go to Android.bp (מעבר אל Android.bp) לצד השדה כדי לעבור להצהרת המודול ב-Android.bp.
• ‫Run on: Device or Host (including host_supported: true): ASfP evaluates the module rule and its transitive defaults chain (host_supported, device_supported, enabled, target.android.enabled, and target.host.enabled):
  • בדיקות עם שני יעדים (cc_test ו-rust_test עם host_supported: true): לחצני הבחירה מכשיר ומארח זמינים (ברירת המחדל היא מכשיר). לכל אחד מהמאפיינים מכשיר ומארח יש תבנית נפרדת משלו לניפוי באגים ב-LLDB. המעבר בין Run on ‏(הפעלה ב) Device ‏(מכשיר) לבין Host ‏(מארח) מחליף בין ההגדרה של המכשיר שמחובר לרשת אחרת lldb-server לבין ההגדרה של הקובץ הבינארי של המארח המקומי, תוך שמירה על ההתאמות האישיות שבוצעו בכל יעד.
  • בדיקות עם יעד יחיד: אם בדיקת C++‎ או Rust מיועדת רק לסביבה אחת (למשל, cc_test רק למכשיר או cc_test_host או rust_test_host רק למארח), ASfP בוחר את היעד הנתמך ומשבית את לחצן הבחירה שלא נתמך עם תיאור קצר: ‫<module> (<ruleType>) doesn't build for the host or device.
• משימות לפני ההשקה (יצירת מודול בדיקה מקורי ופריסה באמצעות atest): כל הגדרה של Soong Test כוללת כברירת מחדל שתי משימות של Before launch:
  • ‫Build Native Test Module (יצירת מודול בדיקה מקורי): יוצר <module>-target (ל-Device) או <module>-host (ל-Host) לפני הפעלת LLDB.
  • פריסה באמצעות atest: כשמבצעים ניפוי באגים במכשיר, מופעלת הפקודה atest <module> --collect-tests-only --disable-teardown -it -s <serial> -- --abi <abi> כך ש-Tradefed דוחף תלות בבדיקה ומבצע הכנות ליעד לפני שהקובץ הבינארי מופעל על ידי LLDB. מציבים את הסמן מעל הצ'יפ Deploy with atest כדי לראות תצוגה מקדימה של הפקודה המדויקת atest. כדי לבצע איטרציה מהירה יותר אחרי שהתלות כבר נמצאת במכשיר, מסירים את Deploy with atest כדי ש-ASfP ידחוף רק את קובץ הבדיקה הבינארי ישירות. כשבוחרים באפשרות Run on: Host, ‏ ASfP מדלג אוטומטית על Deploy with atest.
• שינוי אפשרויות ומנפה הבאגים (כרטיסי אפשרויות של LLDB): משתמשים באפשרות שינוי אפשרויות כדי להוסיף שדות אופציונליים להגדרה:
  • Program arguments (Operating System, C++ and Rust tests only): Extra arguments passed directly to the cc_test or rust_test binary after the --gtest_filter or libtest filter when debugging.
  • ‫atest arguments (Test): דגלים נוספים שמועברים אל atest כשמריצים את הבדיקה או כשמכינים מכשיר באמצעות Deploy with atest.
  • ‫Debugger (בדיקות C++‎ ו-Rust בלבד): מוצג כשModule הוא יעד cc_test* או rust_test*. אפשר להפעיל או להשבית את הכרטיסים LLDB options (למשל Stop on entry,‏ Cache symbols across sessions,‏ Load symbols on demand או With Rust visualizers לבדיקות Rust), ללחוץ על Reset to defaults כדי לאפס את התבנית הפעילה Device או Host, או להוסיף Symbol directories,‏ Init, Pre-run, Post-run, or Exit commands ו-Launch JSON (DAP Settings) מתוך Modify options > Debugger.

צפייה בתוצאות הבדיקה

ההתקדמות של ביצוע הבדיקה, סטטוס ההצלחה או הכישלון, דוחות קריסות וקבצי יומן במכשיר מופיעים בזמן אמת בחלון של הכלי Run או Debug ב-ASfP.

טיפים לבדיקה

• הרצת בדיקות ממוקדות: אפשר לבדוק שיטות ספציפיות בשולי עורך הקוד בלי להריץ חבילת מקרים לבדיקה שלמה.
• שימוש בתמונות מצב של Cuttlefish: כשמריצים בדיקות של מכשירים וירטואליים ב-Cuttlefish, כדאי להשתמש בתמונות מצב כדי לשחזר מצב נקי של המכשיר בין ההרצות.
• בדיקת יומני ה-build של Soong: אם קומפילציה של בדיקה נכשלת לפני ההרצה, צריך לבדוק את חלון הכלים Soong כדי לראות את האבחון של הקומפיילר.