Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Aggiunta di un nuovo esempio di test nativo

Se non conosci lo sviluppo della piattaforma Android, questo esempio completo di aggiunta di un nuovo test nativo da zero è utile per dimostrare il tipico flusso di lavoro. Inoltre, se non si ha familiarità con il framework gtest per C ++, consultare il sito del progetto gtest per ulteriore documentazione.

Questa guida utilizza il seguente test per servire da esempio:

Ciao World Native Test

Si consiglia di consultare prima il codice per ottenere un'impressione approssimativa prima di procedere.

Decidere una posizione di origine

In genere il tuo team avrà già un modello prestabilito di posti per il check-in del codice e luoghi per aggiungere test. La maggior parte dei team possiede un singolo repository git o ne condivide uno con altri team ma ha una sottodirectory dedicata che contiene il codice sorgente del componente.

Supponendo che la posizione della radice per la fonte del componente sia in <component source root> , la maggior parte dei componenti ha src e tests cartelle sotto di essa e alcuni file aggiuntivi come Android.mk (o suddivisi in file .bp aggiuntivi).

Dato che stai aggiungendo un nuovo test, probabilmente dovrai creare la directory dei tests accanto al tuo componente src e popolarla con il contenuto.

In alcuni casi, il team potrebbe avere ulteriori strutture di directory sotto tests causa della necessità di impacchettare diverse suite di test in singoli binari. E in questo caso, dovrai creare una nuova sottodirectory sotto tests .

Per illustrare, ecco un tipico schema di directory per i componenti con una singola cartella tests :

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- src (test source)
          \-- foo_test.cpp
          \-- ...
 

ed ecco un tipico schema di directory per componenti con più directory di sorgenti di test:

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- testFoo (sub test source root)
      |   \-- Android.bp (sub test makefile)
      |   \-- src (sub test source)
      |       \-- test_foo.cpp
      |       \-- ...
      \-- testBar
      |   \-- Android.bp
      |   \-- src
      |       \-- test_bar.cpp
      |       \-- ...
      \-- ...
 

Indipendentemente dalla struttura, finirai per popolare la directory dei tests o la sottodirectory appena creata con file simili a quelli contenuti nella directory native nella modifica di esempio di gerrit. Le sezioni seguenti spiegheranno in ulteriori dettagli di ciascun file.

Codice sorgente

Vedi Hello World Native Test per un esempio.

Il codice sorgente annotato è elencato di seguito:

 #include <gtest/gtest.h>
 

Il file di intestazione include per gtest. Si noti che la dipendenza del file include viene risolta automaticamente usando BUILD_NATIVE_TEST nel makefile

 #include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}
 

I test gtest vengono scritti utilizzando la macro TEST : il primo parametro è il nome del test case e il secondo è il nome del test; insieme al nome binario di prova, formano la gerarchia seguente quando vengono visualizzati nella dashboard dei risultati:

 <test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...
 

Per ulteriori informazioni sulla scrittura di test con gtest, consultare la relativa documentazione:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

File di configurazione semplice

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 impacchettamento. Nella maggior parte dei casi, l'opzione del file Blueprint basata su Soong è sufficiente. Vedere Configurazione semplice del test per i dettagli.

File di configurazione complesso

Per utilizzare Trade Federation invece, scrivi un file di configurazione di test per il cablaggio di test di Android, Trade Federation .

La configurazione di prova può specificare opzioni speciali di impostazione del dispositivo e argomenti predefiniti per fornire la classe di prova.

Costruisci e testa localmente

Per i casi d'uso più comuni, utilizzare Atest .

Per i casi più complessi che richiedono una personalizzazione più pesante, seguire le istruzioni della strumentazione .