Prova la mappatura

Questa è una breve introduzione alla mappatura dei test e una spiegazione su come iniziare a configurare facilmente i test nell'Android Open Source Project (AOSP).

Informazioni sulla mappatura dei test

La mappatura dei test è un approccio basato su Gerrit che consente agli sviluppatori di creare regole di test pre e post invio direttamente nell'albero dei sorgenti Android e lasciare le decisioni sui rami e sui dispositivi da testare all'infrastruttura di test stessa. Le definizioni di mapping dei test sono file JSON denominati TEST_MAPPING che possono essere inseriti in qualsiasi directory di origine.

Atest può utilizzare i file TEST_MAPPING per eseguire test di preinvio nelle directory associate. Con la mappatura dei test, puoi aggiungere lo stesso set di test per preinviare i controlli con una semplice modifica all'interno dell'albero dei sorgenti Android.

Vedi questi esempi:

Aggiungi test di preinvio a TEST_MAPPING per services.core

Aggiungi test di preinvio a TEST_MAPPING per strumenti/dexter utilizzando le importazioni

La mappatura dei test si basa sul Test Harness della Trade Federation (TF) per l'esecuzione dei test e il reporting dei risultati.

Definire i gruppi di test

La mappatura dei test raggruppa i test tramite un gruppo di test . Il nome di un gruppo di test può essere qualsiasi stringa. Ad esempio, il preinvio può riguardare un gruppo di test da eseguire durante la convalida delle modifiche. E i test post-invio possono essere utilizzati per convalidare le build dopo l'unione delle modifiche.

Regole dello script di creazione del pacchetto

Affinché Trade Federation Test Harness possa eseguire i moduli di test della mappatura dei test per una determinata build, questi moduli devono avere test_suite impostato per Soong o LOCAL_COMPATIBILITY_SUITE impostato per Make su una di queste due suite:

  • test-generali : test che non dipendono dalla funzionalità specifica del dispositivo (come l'hardware specifico del fornitore che la maggior parte dei dispositivi non dispone). La maggior parte dei test dovrebbe trovarsi nella suite general-tests, anche se sono specifici per un'ABI o funzionalità bitness o hardware come HWASan (esiste un target test_suites separato per ogni ABI) e anche se devono essere eseguiti su un dispositivo.
  • test-dispositivo : test che dipendono dalla funzionalità specifica del dispositivo. In genere questi test si trovano in vendor/ . Poiché "specifico del dispositivo" non si riferisce alla funzionalità ABI o SoC che altri dispositivi potrebbero o meno avere, ma solo alla funzionalità unica di un dispositivo, questo si applica ai test JUnit tanto quanto ai test nativi GTest (che di solito dovrebbero essere general-tests anche se sono specifici per l'ABI).

Esempi:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Configurare i test da eseguire in una suite di test

Per eseguire un test all'interno di una suite di test, il test:

  • non deve avere alcun provider di build.
  • deve essere ripulito al termine, ad esempio, eliminando eventuali file temporanei generati durante il test.
  • modificare le impostazioni di sistema sul valore predefinito o originale.
  • non dovrebbe presupporre un dispositivo in un determinato stato, ad esempio pronto per il root. La maggior parte dei test non richiede il privilegio di root per essere eseguita. Se un test deve richiedere root, deve specificarlo con RootTargetPreparer nel suo AndroidTest.xml , come nell'esempio seguente:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Creare file di mappatura di prova

Per la directory che richiede la copertura del test, aggiungi semplicemente un file JSON TEST_MAPPING simile all'esempio seguente. Queste regole garantiranno che i test vengano eseguiti nei controlli di preinvio quando vengono toccati file in quella directory o in una qualsiasi delle sue sottodirectory.

Segui un esempio

Ecco un file TEST_MAPPING di esempio (è in formato JSON ma con commenti supportati):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Imposta gli attributi

Nell'esempio precedente, presubmit e postsubmit sono i nomi di ciascun gruppo di test . Vedere Definizione dei gruppi di test per ulteriori informazioni sui gruppi di test.

Il nome del modulo di test o il nome del test di integrazione della Trade Federation (percorso della risorsa al file XML di test, ad esempio, uiautomator/uiautomator-demo ) può essere impostato nel valore dell'attributo name . Tieni presente che il campo del nome non può utilizzare name della classe o name del metodo di test. Per restringere i test da eseguire, puoi utilizzare opzioni come include-filter qui. Vedere ( utilizzo dell'esempio di filtro incluso ).

L'impostazione host di un test indica se il test è un test senza dispositivo in esecuzione sull'host o meno. Il valore predefinito è false , il che significa che il test richiede un dispositivo per essere eseguito. I tipi di test supportati sono HostGTest per i file binari GTest e HostTest per i test JUnit.

L'attributo file_patterns consente di impostare un elenco di stringhe regex per far corrispondere il percorso relativo di qualsiasi file di codice sorgente (relativo alla directory contenente il file TEST_MAPPING). Nell'esempio precedente, il test CtsWindowManagerDeviceTestCases verrà eseguito in preinvio solo quando qualsiasi file Java inizia con Window o Activity, che esiste nella stessa directory del file TEST_MAPPING o in una qualsiasi delle sue sottodirectory, viene modificato. Le barre rovesciate \ devono essere sottoposte a escape poiché si trovano in un file JSON.

L'attributo imports ti consente di includere test in altri file TEST_MAPPING senza copiarne il contenuto. Tieni presente che verranno inclusi anche i file TEST_MAPPING nelle directory principali del percorso importato. La mappatura dei test consente importazioni nidificate; ciò significa che due file TEST_MAPPING possono importarsi a vicenda e la mappatura dei test è in grado di unire correttamente i test inclusi.

L'attributo options contiene opzioni aggiuntive della riga di comando di TradeFed.

Per ottenere un elenco completo delle opzioni disponibili per un determinato test, eseguire:

tradefed.sh run commandAndExit [test_module] --help

Fare riferimento a Gestione delle opzioni di TradeFed per maggiori dettagli su come funzionano le opzioni.

Esegui test con Atest

Per eseguire localmente le regole di test di preinvio:

  1. Vai alla directory contenente il file TEST_MAPPING.
  2. Esegui il comando:
atest

Vengono eseguiti tutti i test di preinvio configurati nei file TEST_MAPPING della directory corrente e delle sue directory principali. Atest individuerà ed eseguirà due test per il preinvio (A e B).

Questo è il modo più semplice per eseguire test di preinvio nei file TEST_MAPPING nella directory di lavoro corrente (CWD) e nelle directory principali. Atest individuerà e utilizzerà il file TEST_MAPPING in CWD e tutte le sue directory principali.

Codice sorgente della struttura

L'esempio seguente mostra come è possibile configurare i file TEST_MAPPING nell'albero di origine.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Contenuto di src/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Contenuto di src/project_1/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Contenuto di src/project_2/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Specificare le directory di destinazione

È possibile specificare una directory di destinazione per eseguire i test nei file TEST_MAPPING in quella directory. Il seguente comando eseguirà due test (A, B).

atest --test-mapping src/project_1

Esegui le regole di test post-invio

Puoi anche utilizzare questo comando per eseguire le regole di test postinvio definite in TEST_MAPPING in src_path (predefinito su CWD) e nelle sue directory principali:

atest [--test-mapping] [src_path]:postsubmit

Esegui solo i test che non richiedono alcun dispositivo

È possibile utilizzare l'opzione --host affinché Atest esegua solo i test configurati sull'host che non richiedono alcun dispositivo. Senza questa opzione, Atest eseguirà entrambi i test, quelli che richiedono il dispositivo e quelli in esecuzione sull'host e non richiedono alcun dispositivo. I test verranno eseguiti in due suite separate.

atest [--test-mapping] --host

Identificare i gruppi di test

È possibile specificare i gruppi di test nel comando Atest. Il seguente comando eseguirà tutti i test postinvio relativi ai file nella directory src/project_1, che contiene solo un test (C).

Oppure puoi usare :all per eseguire tutti i test indipendentemente dal gruppo. Il seguente comando esegue quattro test (A, B, C, X):

atest --test-mapping src/project_1:all

Includi sottodirectory

Per impostazione predefinita, l'esecuzione dei test in TEST_MAPPING con Atest eseguirà solo i test di preinvio configurati nel file TEST_MAPPING in CWD (o nella directory specificata) e nelle relative directory principali. Se vuoi eseguire test in tutti i file TEST_MAPPING nelle sottodirectory, usa l'opzione --include-subdir per forzare Atest a includere anche quei test.

atest --include-subdir

Senza l'opzione --include-subdir , Atest eseguirà solo il test A. Con l'opzione --include-subdir , Atest eseguirà due test (A, B).

È supportato il commento a livello di riga

È possibile aggiungere un commento // formato a livello di riga per arricchire il file TEST_MAPPING con una descrizione dell'impostazione che segue. ATest e Trade Federation preelaboreranno TEST_MAPPING in un formato JSON valido senza commenti. Per mantenere il file JSON pulito e facile da leggere, è supportato solo il commento // -format a livello di riga.

Esempio:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}