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 ulteriori informazioni sul framework GTest per C++, fai riferimento al progetto GTest sito web per documentazione aggiuntiva.
Questa guida utilizza il GTest di Hello World come esempio. Ti consigliamo di leggere attentamente il codice per una comprensione approssimativa prima di continuare.
Scegli una posizione di origine
In genere il team ha già una serie di posti in cui effettuare i controlli nel codice e posizioni in cui aggiungere i test. La maggior parte dei team possiede un unico repository Git condividerne una con altri team, ma avere una sottodirectory dedicata che contiene il codice sorgente del componente.
Supponendo che la posizione principale dell'origine del componente sia in <component source
root>, la maggior parte dei componenti ha src e tests cartelle al di sotto e alcune
file aggiuntivi come Android.mk (o suddivisi in .bp aggiuntivi
).
Dato che stai aggiungendo un nuovo test, probabilmente dovrai creare il
tests accanto al componente src e compilala con dei 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 directory secondaria in tests.
Ecco un esempio di struttura tipica di una directory per i componenti con un
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
alla sottodirectory appena creata con file simili a quelli presenti nell'elemento native
nella modifica gerrit di esempio. Le sezioni seguenti spiegano in
ulteriori dettagli di ogni file.
Codice sorgente
Fai riferimento al GTest di Hello World. per vedere un esempio.
Il codice sorgente per questo esempio è annotato qui:
#include <gtest/gtest.h>
Il file di intestazione include per GTest. La dipendenza del file di inclusione viene
risolto 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 è lo scenario di test
e il secondo è il nome del test. Insieme al nome del programma binario di test, formano il
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 metadati dei moduli, dipendenze del tempo di compilazione e pacchetti istruzioni. Nella maggior parte dei casi, l'opzione File Blueprint basato su Presto è sufficienti. Per maggiori dettagli, vedi Configurazione di test semplice.
File di configurazione complesso
Per utilizzare la Trade Federation, scrivi una configurazione di test per il sistema di test di Android, la Trade Federation.
La configurazione di test può specificare opzioni speciali di configurazione del dispositivo e impostazioni predefinite per fornire la classe di test.
Creazione e test in locale
Per i casi d'uso più comuni, utilizza Conferma.
Per i casi più complessi che richiedono una personalizzazione più intensa, segui le istruzioni sulla strumentazione.