Se sei nuovo nello sviluppo della piattaforma Android, potresti trovare utile questo esempio completo di aggiunta di un binario GTest nuovo di zecca (a volte chiamato anche test "nativo") da zero per dimostrare il tipico flusso di lavoro coinvolto. Per ulteriori informazioni sul framework GTest per C++, fare riferimento al sito del progetto GTest per ulteriore documentazione.
Questa guida utilizza Hello World GTest come esempio. Ti consigliamo di leggere il codice per avere una comprensione approssimativa prima di continuare.
Decidere su una posizione di origine
In genere il tuo team avrà già uno schema stabilito di punti in cui archiviare 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 dispone di una sottodirectory dedicata che contiene il codice sorgente del componente.
Supponendo che la posizione root per l'origine del componente sia <component source root> , la maggior parte dei componenti contiene cartelle src e tests e alcuni file aggiuntivi come Android.mk (o suddivisi in file .bp aggiuntivi).
Poiché stai aggiungendo un test nuovo di zecca, probabilmente dovrai creare la directory 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 a causa della necessità di impacchettare diverse suite di test in singoli file 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 i 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 presenti nella directory native nella modifica gerrit di esempio. Le sezioni seguenti spiegheranno in ulteriori dettagli di ciascun file.
Codice sorgente
Fare riferimento a Hello World GTest per un esempio.
Il codice sorgente per quell'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 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 del 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, fare riferimento alla documentazione di GTest
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 impacchettamento. Nella maggior parte dei casi, l'opzione del file Blueprint basata su Soong è sufficiente. Vedere Configurazione test semplice per i dettagli.
File di configurazione complesso
Per utilizzare invece Trade Federation, scrivi un file di configurazione di test 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 testa in locale
Per i casi d'uso più comuni, utilizzare Atest .
Per casi più complessi che richiedono una personalizzazione più pesante, seguire le istruzioni sulla strumentazione .