Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Aggiunta di un nuovo esempio di test nativo

Se sei nuovo nello sviluppo della piattaforma Android, potresti trovare questo esempio completo di aggiunta di un nuovissimo test nativo da zero utile per dimostrare il tipico flusso di lavoro coinvolto. Inoltre, se non hai familiarità con il framework gtest per C ++, consulta il sito del progetto gtest per ulteriore documentazione.

Questa guida utilizza il seguente test per fungere da campione:

Hello World Native Test

Si consiglia di sfogliare prima il codice per avere un'idea approssimativa prima di procedere.

Decidere una posizione di origine

In genere il tuo team avrà già uno schema stabilito di posizioni in cui archiviare il codice e luoghi in cui 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 principale per l'origine del componente sia in <component source root> , la maggior parte dei componenti ha src e cartelle di tests 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 tuo 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 di 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 tests o la sottodirectory appena creata con file simili a quelli che si trovano nella directory native nella modifica di gerrit di esempio. Le sezioni seguenti spiegheranno in modo più dettagliato ogni file.

Codice sorgente

Vedere 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. Notare che la dipendenza del file di inclusione viene risolta automaticamente utilizzando BUILD_NATIVE_TEST nel makefile

#include <stdio.h>

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

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, vedere 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 dirigere il sistema di compilazione con i metadati del modulo, le dipendenze in fase di compilazione e le istruzioni di pacchettizzazione. Nella maggior parte dei casi, l'opzione del file Blueprint basata su Soong è sufficiente. Vedere Configurazione di test semplice per i dettagli.

File di configurazione complesso

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

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

Crea e prova a livello locale

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

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