Ogni nuovo modulo di test deve avere un file di configurazione per indirizzare il sistema di compilazione con metadati del modulo, dipendenze in fase di compilazione e istruzioni di packaging. Android ora utilizza il sistema di compilazione Soong per una configurazione dei test più semplice.
Soong utilizza file Blueprint o .bp
, che sono descrizioni dichiarative semplici simili a JSON dei moduli da compilare. Questo formato sostituisce il sistema basato su Make
utilizzato nelle versioni precedenti. Per maggiori dettagli, consulta i file di riferimento di Soong nella dashboard di integrazione continua.
Per eseguire test personalizzati o utilizzare la suite di test di compatibilità (CTS) di Android, segui Configurazione di test complessi.
Esempio
Le voci riportate di seguito provengono da questo file di configurazione del progetto iniziale di esempio: /platform_testing/tests/example/instrumentation/Android.bp
Per comodità, è incluso uno snapshot:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Tieni presente che la dichiarazione android_test
all'inizio indica che si tratta di un test.
L'inclusione di android_app
indicherebbe invece che si tratta di un pacchetto di build.
Impostazioni
Le seguenti impostazioni richiedono una spiegazione:
name: "HelloWorldTests",
L'impostazione name
è obbligatoria quando viene specificato il tipo di modulo android_test
(all'inizio del blocco). Assegna un nome al modulo e l'APK risultante avrà lo stesso nome e un suffisso .apk
, ad esempio, in questo caso, l'APK di test risultante si chiama HelloWorldTests.apk
. Inoltre, definisce anche un nome di destinazione make per il modulo, in modo da poter utilizzare make [options]
<HelloWorldTests>
per creare il modulo di test e tutte le relative dipendenze.
static_libs: ["androidx.test.runner"],
L'impostazione static_libs
indica al sistema di compilazione di incorporare i contenuti
dei moduli denominati nell'APK risultante del modulo corrente. Ciò significa che
ogni modulo denominato deve produrre un file .jar
e il suo contenuto verrà
utilizzato per risolvere i riferimenti al classpath durante la compilazione, nonché
incorporato nell'apk risultante.
Il modulo androidx.test.runner
è predefinito per la libreria AndroidX Test Runner, che include il test runner AndroidJUnitRunner
.
AndroidJUnitRunner
supporta il framework di test JUnit4 e ha sostituito
InstrumentationTestRunner
in Android 10. Scopri di più
sui test delle app per Android in Testare le app su Android.
Se stai creando un nuovo modulo di strumentazione, devi sempre iniziare con la libreria androidx.test.runner
come test runner. L'albero delle origini della piattaforma
include anche altri framework di test utili come ub-uiautomator
,
mockito-target
, easymock
e altri ancora.
certificate: "platform",
L'impostazione certificate
indica al sistema di build di firmare l'APK con lo stesso
certificato della piattaforma principale. Questo è necessario se il test utilizza un'autorizzazione o un'API
protetta da firma. Tieni presente che questo è adatto per i test continui della piattaforma, ma non deve essere utilizzato nei moduli di test CTS. Tieni presente che questo esempio
utilizza questa impostazione del certificato solo a scopo illustrativo: il codice di test
dell'esempio non richiede effettivamente che l'APK di test sia firmato con il
certificato della piattaforma speciale.
Se stai scrivendo un'instrumentazione per il tuo componente che si trova al di fuori del server di sistema, ovvero è pacchettizzato più o meno come un normale APK dell'app, tranne per il fatto che è integrato nell'immagine di sistema e potrebbe essere un'app con privilegi, è probabile che la tua instrumentazione abbia come target il pacchetto dell'app (vedi la sezione seguente sul manifest) del tuo componente. In questo caso, il makefile dell'applicazione
potrebbe avere la propria impostazione certificate
e il modulo di strumentazione
dovrebbe mantenere la stessa impostazione. Questo perché per indirizzare
la strumentazione sull'app in fase di test, l'APK di test e l'APK dell'app devono essere firmati
con lo stesso certificato.
In altri casi, non è necessario disporre di questa impostazione: il sistema di build
lo firmerà semplicemente con un certificato predefinito integrato, in base alla variante
di build, e in genere viene chiamato dev-keys
.
test_suites: ["device-tests"],
L'impostazione test_suites
rende il test facilmente individuabile dal framework di test Trade
Federation. Qui possono essere aggiunte altre suite, ad esempio CTS, in modo che questo test possa essere condiviso.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Impostazioni facoltative
Le seguenti impostazioni facoltative richiedono una spiegazione:
test_config: "path/to/hello_world_test.xml"
L'impostazione test_config
indica al sistema di compilazione che la destinazione del test richiede una
configurazione specifica. Per impostazione predefinita, un AndroidTest.xml
accanto a Android.bp
è
associato alla configurazione.
auto_gen_config: true
L'impostazione auto_gen_config
indica se creare o meno automaticamente la configurazione di test. Se AndroidTest.xml
non esiste accanto a Android.bp
, questo
attributo non deve essere impostato su true in modo esplicito.
require_root: true
L'impostazione require_root
indica al sistema di compilazione di aggiungere RootTargetPreparer
alla configurazione di test generata automaticamente. In questo modo, il test viene eseguito con autorizzazioni di root.
test_min_api_level: 29
L'impostazione test_min_api_level
indica al sistema di compilazione di aggiungere
MinApiLevelModuleController alla configurazione di test generata automaticamente. Quando Trade
Federation esegue la configurazione di test, il test verrà ignorato se la proprietà del dispositivo
di ro.product.first_api_level
< test_min_api_level
.