Se sei nuovo nello sviluppo della piattaforma Android, potresti trovare utile questo esempio completo di aggiunta di un nuovissimo binario GTest (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 comprenderlo approssimativamente prima di continuare.
Decidi la posizione della fonte
In genere il tuo team avrà già uno schema stabilito di luoghi in cui effettuare il check-in del codice e di 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 dell'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).
Dato che 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 raggruppare diverse suite di test in singoli file binari. E in questo caso, dovrai creare una nuova sottodirectory sotto tests .
Per illustrare, ecco una tipica struttura 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 una tipica struttura di directory per componenti con più directory di origine del 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 contenuti nella directory native nell'esempio gerrit change. Le sezioni seguenti spiegheranno in ulteriori dettagli 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>
Il file di intestazione include 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 nel 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 dei 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 metadati del modulo, dipendenze in fase di compilazione e istruzioni di confezionamento. Nella maggior parte dei casi, l'opzione file Blueprint basata su Soong è sufficiente. Per i dettagli vedere Configurazione test semplice .
File di configurazione complesso
Per utilizzare invece Trade Federation, scrivi un file di configurazione di prova per il test cablaggio 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.
Costruisci e testa localmente
Per i casi d'uso più comuni, utilizzare Atest .
Per casi più complessi che richiedono personalizzazioni più impegnative, seguire le istruzioni della strumentazione .