Se non hai mai sviluppato per la piattaforma Android, questo esempio completo di aggiunta di un nuovo binario GTest (a volte chiamato anche test "nativo") da zero potrebbe esserti utile per illustrare il flusso di lavoro tipico. Per ulteriori informazioni sul framework GTest per C++, consulta il sito del progetto GTest per la documentazione aggiuntiva.
Questa guida utilizza l'esempio Hello World GTest. Ti consigliamo di leggere il codice per comprenderlo a grandi linee prima di continuare.
Scegliere una posizione di origine
In genere, il tuo team avrà già un pattern consolidato di posizioni in cui controllare il codice e posizioni in cui aggiungere i 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 del codice sorgente del componente sia <component source
root>, la maggior parte dei componenti ha le cartelle src e tests al suo interno, oltre ad alcuni
file aggiuntivi come Android.mk (o suddivisi in file .bp
aggiuntivi).
Poiché stai aggiungendo un nuovo test, probabilmente dovrai creare la directory tests accanto a src del componente e inserirvi i contenuti.
In alcuni casi, il tuo team potrebbe avere ulteriori 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.
Per illustrare, ecco una struttura di directory tipica 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 una struttura di directory tipica per i componenti con più directory di origine dei 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 inserire nella directory tests o nella sottodirectory appena creata file simili a quelli presenti nella directory native nella modifica di esempio di Gerrit. Le sezioni seguenti spiegheranno in dettaglio ogni file.
Codice sorgente
Per un esempio, consulta Hello World GTest.
Il codice sorgente di questo esempio è annotato qui:
#include <gtest/gtest.h>
File di intestazione per GTest. La dipendenza del file di inclusione viene risolta automaticamente utilizzando BUILD_NATIVE_TEST nel makefile.
#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 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 pacchettizzazione. Nella maggior parte dei casi, l'opzione del file Blueprint basata su Soong è sufficiente. Per maggiori dettagli, consulta Configurazione di test semplice.
File di configurazione complesso
consulta la Configurazione di test complessa.Per utilizzare Trade Federation, scrivi un file di configurazione di test per l'ambiente di test di Android, Trade Federation.
La configurazione di test può specificare opzioni di configurazione speciali del dispositivo e argomenti predefiniti da fornire alla classe di test.
Crea build ed esegui test in locale
Per i casi d'uso più comuni, utilizza Atest.
Per i casi più complessi che richiedono una personalizzazione più approfondita, segui le istruzioni di strumentazione.