Se non hai esperienza nello sviluppo per la piattaforma Android, potresti trovare utile questo esempio completo di aggiunta di un nuovo file binario GTest (a volte chiamato anche test "nativo") da zero per dimostrare il flusso di lavoro tipico. Per informazioni aggiuntive sul framework GTest per C++, consulta il sito del progetto GTest per ulteriore documentazione.
Questa guida utilizza Hello World GTest come esempio. Ti consigliamo di leggere il codice per avere una vaga idea di cosa si tratta prima di continuare.
Scegli una posizione di origine
In genere, il tuo team avrà già stabilito una serie di punti di controllo nel codice e punti in cui aggiungere test. La maggior parte dei team possiede un singolo repository Git o lo condivide con altri team, ma dispone di una sottodirectory dedicata che contiene il codice sorgente dei componenti.
Supponendo che la posizione principale del codice sorgente del componente sia <component source
root>, la maggior parte dei componenti ha cartelle src e tests al suo interno e alcuni file aggiuntivi come Android.mk (o suddivisi in altri file .bp).
Poiché stai aggiungendo un test nuovo di zecca, probabilmente dovrai creare la directory tests accanto al componente src e compilarla con i contenuti.
In alcuni casi, il team potrebbe avere altre strutture di directory in tests
a causa della necessità di pacchettizzare diverse suite di test in singoli binari.
In questo caso, dovrai creare una nuova sottodirectory in tests.
A titolo esemplificativo, di seguito è riportato un riassunto di directory tipico per i componenti con una singola
tests cartella:
\
<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 i componenti con più directory di origine 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 compilare la directory tests o la sottodirectory appena creata con file simili a quelli contenuti nella directory native nella modifica di gerrit di esempio. Le sezioni seguenti forniscono maggiori dettagli su ciascun file.
Codice sorgente
Per un esempio, consulta Hello World GTest.
Il codice sorgente dell'esempio è annotato qui:
#include <gtest/gtest.h>
Include file di intestazione per GTest. La dipendenza dal file include viene risolta automaticamente utilizzando BUILD_NATIVE_TEST nel file make.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
I GTest vengono scritti utilizzando la macro TEST: il primo parametro è il nome del caso di test e il secondo è il nome del test. Insieme al nome del programma binario di test, formano la seguente gerarchia 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, consulta la documentazione di GTest.
File di configurazione semplice
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. Nella maggior parte dei casi, l'opzione del file Blueprint basato su Soong è sufficiente. Per maggiori dettagli, consulta la sezione Configurazione di test semplici.
File di configurazione complesso
Per utilizzare invece Trade Federation, scrivi un file di configurazione del test per Trade Federation, l'ambiente di test di Android.
La configurazione del test può specificare opzioni di configurazione del dispositivo speciali e argomenti predefinite per fornire la classe di test.
Esegui la compilazione e i test in locale
Per i casi d'uso più comuni, utilizza Atest.
Per casi più complessi che richiedono una maggiore personalizzazione, segui le istruzioni di strumentazione.