Testowanie kodu platformy za pomocą narzędzia atest

Android Studio for Platform (ASfP) integruje się z modułami testowymi atest i Soong, dzięki czemu możesz uruchamiać i debugować testy platformy na komputerze hosta z systemem Linux, podłączonym urządzeniu lub wirtualnym urządzeniu Cuttlefish z poziomu IDE.

Wymagania wstępne

  • Otwórz projekt ASfP skonfigurowany z wersją AOSP i lunch.
  • W przypadku testów urządzeń podłącz urządzenie fizyczne lub uruchom wirtualne urządzenie Cuttlefish z odpowiednią kompilacją.

Uruchamianie i debugowanie testów

Testy platformy i sesje debugowania możesz uruchamiać w kilku miejscach w ASfP:

  • Android.bp cele testu: otwórz plik Android.bp i kliknij Uruchom w marginesie obok dowolnego modułu testowego (*_test lub *_test_host):
    • Uruchom: dostępne dla wszystkich typów modułów testowych Soong (android_test, java_test_host, cc_test, rust_test, python_test, sh_test i android_robolectric_test).
    • Debug: dostępne w przypadku modułów android_test (dołączonych do debugera Java za pomocą atest --wait-for-debugger) i modułów testowych C++ lub Rust (cc_test, cc_test_host, rust_test i rust_test_host, uruchamianych w ramach wbudowanego debugera LLDB w ASfP).
  • Ikony w kolumnie pliku źródłowego: kliknij Uruchom obok klasy testowej lub @Testmetody w kodzie źródłowym, aby uruchomić lub debugować konkretny test.
  • Menu kontekstowe po kliknięciu prawym przyciskiem myszy: kliknij prawym przyciskiem myszy plik testowy, klasę, metodę lub moduł Android.bp i wybierz Uruchom lub Debuguj.
  • Wbudowany agent (AI w Android Studio): w oknie narzędziowym Agent wbudowany agent może uruchamiać atestcele, aby weryfikować zmiany po edycji kodu.
  • Zintegrowany terminal: otwórz Widok > Okna narzędzi > Terminal, aby bezpośrednio uruchamiać poleceniaatest.

Konfigurowanie i debugowanie testu inteligentnego

Gdy uruchomisz test z marginesu lub menu kontekstowego, ASfP utworzy i skonfiguruje konfigurację uruchamiania testu Soong za pomocą wykresu modułu Android.bp.

Debugowanie android_test celów Java i Kotlin

Kliknij ikonę rynny obok modułu android_test w Android.bp lub obok klasy JUnit w języku Java lub Kotlin albo metody @Test, a potem wybierz Debuguj „<TestName>”. W przypadku rynny pliku źródłowego ASfP wybiera najbliższy moduł android_test, którego srcs obejmuje plik, i nadaje konfiguracji nazwę <module>, <module>:<SimpleClass> lub <module>:<SimpleClass>#<method>.

ASfP uruchamia atest z parametrem --wait-for-debugger, odczytuje atrybut package z AndroidManifest.xml modułu, czeka na zakończenie tego procesu na podłączonym urządzeniu i dołącza debuger języka Java.

Debugowanie metody android_test z poziomu rynny edytora

Debugowanie celów cc_test i rust_test w LLDB

Aby debugować moduł testowy C++ lub Rust (cc_test, cc_test_host, rust_test lub rust_test_host), kliknij ikonę Android.bp na marginesie i wybierz Debuguj „<TestName>”. ASfP uruchomi skompilowany plik binarny testu w wbudowanym debuggerze LLDB zamiast uruchamiać go za pomocą atest.

Skonfiguruj konfigurację testu Soong

Otwórz Uruchom > Edytuj konfiguracje i wybierz konfigurację Test Soong, aby dostosować sposób kompilowania, wdrażania i uruchamiania testów:

  • Automatyczne uzupełnianie modułów i Android.bp nawigacja: pole Moduł automatycznie uzupełnia się na podstawie zindeksowanych modułów testowych Soong w projekcie. Kliknij Go to Android.bp (Przejdź do Android.bp) obok pola, aby przejść do deklaracji modułu w Android.bp.
  • Uruchomienie: urządzenie lub host (w tym host_supported: true): ASfP ocenia regułę modułu i jej przechodni łańcuch defaults (host_supported, device_supported, enabled, target.android.enabled i target.host.enabled):
    • Testy z 2 rodzajami kierowania (cc_test i rust_test z host_supported: true): dostępne są oba przyciski radiowe Urządzenie i Host (domyślnie wybrany jest przycisk Urządzenie). Urządzenie i Host mają własne, niezależne szablony debugera LLDB. Przełączanie opcji Uruchom między Urządzeniem a Hostem powoduje przełączanie się między konfiguracją urządzenia zdalnegolldb-server a konfiguracją lokalnego pliku binarnego hostalldb-server z zachowaniem dostosowań wprowadzonych w każdym miejscu docelowym.
    • Testy z jednym celem: jeśli test w C++ lub Rust jest kompilowany tylko w jednym środowisku (np. tylko na urządzeniu cc_test lub tylko na hoście cc_test_host albo rust_test_host), ASfP wybiera obsługiwany cel i wyłącza nieobsługiwany przycisk opcji z wyjaśniającą etykietką: „<module> (<ruleType>) doesn't build for the host or device.”.
  • Zadania przed uruchomieniem (Build Native Test Module i Deploy with atest): każda konfiguracja testu Soong domyślnie zawiera 2 zadania przed uruchomieniem:
    • Build Native Test Module (Skompiluj natywny moduł testowy): przed uruchomieniem LLDB kompiluje <module>-target (w przypadku urządzenia) lub <module>-host (w przypadku hosta).
    • Wdrażanie za pomocą polecenia atest: podczas debugowania na urządzeniu uruchamia atest <module> --collect-tests-only --disable-teardown -it -s <serial> -- --abi <abi>, dzięki czemu Tradefed przesyła zależności testowe i wykonuje preparatory docelowe przed uruchomieniem pliku binarnego przez LLDB. Najedź wskaźnikiem na element Wdróż za pomocą atestu, aby wyświetlić podgląd dokładnego polecenia atest. Aby przyspieszyć iterację, gdy zależności są już na urządzeniu, usuń Deploy with atest, aby ASfP przesyłał bezpośrednio tylko plik binarny testu. Jeśli wybierzesz Uruchom na: host, ASfP automatycznie pominie opcję Wdróż z testem.
  • Opcje modyfikacji i debugger (karty opcji LLDB): użyj opcji Modyfikuj opcje, aby dodać opcjonalne pola konfiguracji:
    • Argumenty programu (system operacyjny, tylko testy C++ i Rust): dodatkowe argumenty przekazywane bezpośrednio do pliku binarnego cc_test lub rust_test po filtrze --gtest_filter lub libtest podczas debugowania.
    • atest arguments (Test): dodatkowe flagi przekazywane do atest podczas uruchamiania testu lub przygotowywania urządzenia za pomocą opcji Deploy with atest (Wdróż za pomocą atest).
    • Debuger (tylko testy w C++ i Rust): wyświetla się, gdy Moduł jest celem cc_test* lub rust_test*. Przełącz karty LLDB options (Opcje LLDB) (np. Stop on entry (Zatrzymaj przy wejściu), Cache symbols across sessions (Buforuj symbole w różnych sesjach), Load symbols on demand (Wczytuj symbole na żądanie) lub With Rust visualizers (Z wizualizatorami Rust) w przypadku testów Rust), kliknij Reset to defaults (Przywróć ustawienia domyślne), aby zresetować aktywny szablon Device (Urządzenie) lub Host (Host), albo dodaj Symbol directories (Katalogi symboli), Init, Pre-run, Post-run, or Exit commands (Polecenia inicjowania, przed uruchomieniem, po uruchomieniu lub wyjścia) i Launch JSON (DAP Settings) (Ustawienia DAP) w sekcji Modify options > Debugger (Modyfikuj opcje > Debuger).

Konfiguracja uruchomienia testu Soong z wyświetlonymi zadaniami przed uruchomieniem, elementami docelowymi urządzenia lub hosta oraz opcjami LLDB

Wyświetlanie wyników testu

Postępy wykonywania testu, stan (sukces lub niepowodzenie), zrzuty stosu i dzienniki urządzeń są wyświetlane w czasie rzeczywistym w oknie narzędzia Uruchom lub Debuguj w ASfP.

Wskazówki dotyczące testowania

  • Przeprowadzanie ukierunkowanych testów: testuj poszczególne metody z marginesu edytora bez uruchamiania całego zestawu testów.
  • Używaj migawek Cuttlefish: podczas przeprowadzania testów urządzeń na wirtualnych urządzeniach Cuttlefish używaj migawek, aby przywracać czysty stan urządzenia między kolejnymi uruchomieniami.
  • Sprawdzanie dzienników kompilacji Soong: jeśli test nie skompiluje się przed uruchomieniem, sprawdź okno narzędzia Soong pod kątem diagnostyki kompilatora.