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 Hello World GTest come esempio. Ti consigliamo di leggere il codice per farti un'idea generale prima di continuare.
Scegliere una posizione di origine
In genere, il tuo team avrà già un pattern consolidato di luoghi in cui controllare il codice e luoghi 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 dell'origine del componente sia <component source
root>, la maggior parte dei componenti ha le 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 completamente nuovo, probabilmente dovrai creare la directory
tests accanto al componente src e popolarla con i contenuti.
In alcuni casi, il tuo team potrebbe avere ulteriori strutture di directory in tests
a causa della necessità di raggruppare diverse suite di test in singoli file binari.
In questo caso, dovrai creare una nuova sottodirectory in tests.
Per illustrare, ecco una struttura tipica 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
\-- ...
Ecco una struttura tipica della directory 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 compilare la directory tests o la sottodirectory appena creata con file simili a quelli della directory native nella modifica di esempio di Gerrit. Le sezioni seguenti spiegheranno in
maggiori dettagli ciascun 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 incluso 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 test GTest vengono scritti utilizzando la macro TEST: il primo parametro è il nome dello scenario 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 saperne di più 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 metadati del modulo, dipendenze in fase di compilazione e istruzioni di packaging. Nella maggior parte dei casi, l'opzione del file Blueprint basato su Soong è sufficiente. Per maggiori dettagli, consulta Configurazione semplice del test.
File di configurazione complesso
Per utilizzare Trade Federation, scrivi un file di configurazione di test per il framework di test di Android, Trade Federation.
La configurazione del test può specificare opzioni speciali di configurazione del dispositivo e argomenti predefiniti per fornire la classe di test.
Creare build e testare 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.