Aggiunta di nuovi GoogleTests (GTests)

Se non conosci lo sviluppo della piattaforma Android, potresti trovare da zero questo esempio completo di aggiunta di un file binario GTest nuovo di zecca (a volte chiamato anche test "nativo") utile 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 una posizione di origine

In genere il tuo team avrà già uno schema stabilito di luoghi in cui archiviare il codice e luoghi in cui aggiungere 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 per l'origine del componente sia in <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 durante tests a causa della necessità di impacchettare diverse suite di test in singoli file binari. E in questo caso, dovrai creare una nuova sottodirectory in 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 uno schema di directory tipico 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 popolare la directory tests o la sottodirectory appena creata con file simili a quelli che si trovano nella directory native nel cambio 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>

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 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, fare riferimento alla 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 confezionamento. Nella maggior parte dei casi, l'opzione del 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 test per il test harness di Android, Trade Federation .

La configurazione del test può specificare opzioni di configurazione del dispositivo speciali e argomenti predefiniti per fornire la classe di test.

Crea e testa localmente

Per i casi d'uso più comuni, utilizzare Atest .

Per i casi più complessi che richiedono una personalizzazione più pesante, seguire le istruzioni della strumentazione .