Ogni nuovo modulo di test deve avere un file di configurazione per indirizzare il sistema di compilazione con i metadati del modulo, le dipendenze in fase di compilazione e le istruzioni di imballaggio. Android ora utilizza il sistema di compilazione Soong per una configurazione dei test più semplice.
Soong utilizza file Blueprint o .bp, ovvero descrizioni declarative semplici simili a JSON dei moduli da compilare. Questo formato sostituisce il sistema basato su Make
utilizzato nelle release precedenti. Per maggiori dettagli, consulta i file di riferimento di Soong nella dashboard di integrazione continua.
Per eseguire test personalizzati o utilizzare la Compatibility Test Suite (CTS) di Android, segui la procedura descritta in Configurazione di test complessi.
Esempio
Le voci riportate di seguito provengono da questo file di configurazione di Blueprint 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 indica invece che si tratta di un pacchetto di compilazione.
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 è denominato HelloWorldTests.apk. Inoltre, viene definito anche un nome target di build per il modulo, in modo da poter utilizzare make [options]
<HelloWorldTests> per compilare 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
degli elementi denominati nell'APK risultante del modulo corrente. Ciò significa che
ogni modulo denominato deve produrre un file .jar e i relativi contenuti verranno
utilizzati per risolvere i riferimenti del percorso di classe durante il tempo di compilazione, nonché
incorporati 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ù su come testare le app per Android nella pagina Testare le app su Android.
Se stai creando un nuovo modulo di misurazione, devi sempre iniziare con la libreria androidx.test.runner come programma di test. La struttura ad albero delle sorgenti 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 compilazione di firmare l'APK con lo stesso
certificato della piattaforma di base. Questo è necessario se il test utilizza un'API o un'autorizzazione protetta con 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 una misurazione 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,
a parte che è integrato nell'immagine di sistema e potrebbe essere un'app privilegiata, è probabile
che la misurazione abbia come target il pacchetto dell'app (vedi di seguito
la sezione relativa al 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 scegliere come target la tua instrumentation nell'app in 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 compilazione lo firmerà semplicemente con un certificato predefinito integrato, in base alla variante di compilazione, e in genere si chiama dev-keys.
test_suites: ["device-tests"],
L'impostazione test_suites rende il test facilmente rilevabile dall'ambiente di test della Federazione di commercianti. 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 compilazione che il target di test richiede una configurazione specifica. Per impostazione predefinita, un AndroidTest.xml accanto al Android.bp è associato alla configurazione.
auto_gen_config: true
L'impostazione auto_gen_config indica se creare o meno la configurazione del 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 dei test generata automaticamente. In questo modo, il test verrà eseguito con le 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 viene ignorato se la proprietà del dispositivo
ro.product.first_api_level è inferiore a test_min_api_level.