Ogni nuovo modulo di test deve avere un file di configurazione per indirizzare il sistema di compilazione con metadati dei moduli, dipendenze del tempo di compilazione e istruzioni di pacchettizzazione. Ora Android utilizza il sistema di compilazione Soong per configurazione di test.
prestog utilizza file Blueprint o .bp
, che sono semplici dichiarazioni dichiarative di tipo JSON
le descrizioni dei moduli da creare. Questo formato sostituisce il sistema basato su marca
utilizzati nelle release precedenti. Per maggiori dettagli, consulta i file di riferimento di Soong nella dashboard di integrazione continua.
Per supportare i test personalizzati o utilizzare Android Compatibility Test Suite (CTS), segui Configurazione dei test complessi .
Esempio
Le voci seguenti provengono da questo file di configurazione di progetto di esempio: /platform_testing/tests/example/instrumentation/Android.bp
Per praticità viene incluso qui un'istantanea:
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
indica invece che si tratta di un pacchetto di compilazione.
Impostazioni
Le seguenti impostazioni ti spiegano:
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 i risultati
L'APK avrà lo stesso nome e avrà un suffisso .apk
, ad esempio In questo caso,
l'APK di test risultante è denominato HelloWorldTests.apk
. Inoltre,
definisce un nome di destinazione per il modulo, in modo che tu possa utilizzare make [options]
<HelloWorldTests>
per creare il modulo di test e tutte le sue 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 dovrebbe generare un file .jar
e il suo contenuto
utilizzato per risolvere i riferimenti di classpath durante la compilazione, nonché
incorporato nell'APK risultante.
Il modulo androidx.test.runner
è predefinito per AndroidX Test Runner
Libreria che include l'esecutore del test AndroidJUnitRunner
.
AndroidJUnitRunner
supporta il framework di test JUnit4 e ha sostituito
InstrumentationTestRunner
in Android 10. Scopri di più su come testare le app per Android nella pagina Testare le app su Android.
Se stai creando un nuovo modulo di strumentazione, dovresti sempre iniziare con
la raccolta androidx.test.runner
come runner del test. L'albero di origine della piattaforma
include anche altri framework di test utili, come ub-uiautomator
,
mockito-target
, easymock
e altri.
certificate: "platform",
L'impostazione certificate
indica al sistema di compilazione di firmare l'APK con lo stesso
come piattaforma di base. Questa autorizzazione è necessaria se il test utilizza una firma
in un'API o in un'autorizzazione protetta. Tieni presente che questa funzionalità è adatta per i carichi di lavoro
ma non devono essere utilizzati nei moduli di test CTS. Tieni presente che questo esempio
utilizza questa impostazione del certificato a solo scopo illustrativo: il codice di test
dell'esempio non è necessario che l'APK di prova sia firmato con
certificato speciale della piattaforma.
Se stai scrivendo una strumentazione per il tuo componente che risiede al di fuori del
server di sistema, ovvero è pacchettizzato più o meno come un normale APK di app,
tranne che è integrata nell'immagine di sistema e potrebbe essere un'app con privilegi,
è che la tua strumentazione avrà come target il pacchetto dell'app (vedi di seguito
relativa al file manifest) del tuo componente. In questo caso, il file makefile dell'applicazione potrebbe avere una propria impostazione certificate
e il modulo di misurazione dovrebbe mantenere la stessa impostazione. Ciò è dovuto al fatto che per scegliere come target
strumentazione nell'app in fase di test, devi firmare l'APK di test e l'APK dell'app
con lo stesso certificato.
In altri casi, questa impostazione non è necessaria: il sistema di compilazione
la firma con un certificato predefinito integrato, basato sulla build
ed è generalmente chiamata dev-keys
.
test_suites: ["device-tests"],
L'impostazione test_suites
consente di trovare facilmente il test da parte del
Imbracatura di test della federazione. Qui è possibile aggiungere altre suite, ad esempio CTS, in modo da condividere questo
test.
${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 build che è necessario per il target di test
una configurazione specifica. Per impostazione predefinita, un AndroidTest.xml
accanto a Android.bp
è
associati alla configurazione.
auto_gen_config: true
L'impostazione auto_gen_config
indica se creare o meno la configurazione di test
automaticamente. 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. Ciò garantisce che il test venga eseguito con root
autorizzazioni aggiuntive.
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 viene negoziato
La federazione esegue la configurazione di test; il test verrà ignorato se la proprietà del dispositivo
di ro.product.first_api_level
< test_min_api_level
.