Aggiunta di un nuovo esempio di test nativo

Se non conosci lo sviluppo della piattaforma Android, potresti trovare utile questo esempio completo di aggiunta di un test nativo nuovo di zecca per dimostrare il flusso di lavoro tipico coinvolto. Inoltre, se siete anche familiarità con il quadro GTEST per C ++, si prega di consultare il sito del progetto GTEST per la documentazione aggiuntiva.

Questa guida utilizza il seguente test come esempio:

Ciao World Native Test

Si consiglia di sfogliare prima il codice per avere un'idea approssimativa prima di procedere.

Decidere su una posizione di origine

In genere il tuo team avrà già un modello stabilito di posti per il check-in del codice e posti per 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 per la vostra fonte componente è a <component source root> , la maggior parte dei componenti hanno src e tests cartelle sotto di essa, e alcuni file aggiuntivi, come Android.mk (o suddiviso in ulteriori .bp file).

Dal momento che si sta aggiungendo un nuovo test, è probabilmente necessario creare il tests directory successiva al componente src , e popolarlo con i contenuti.

In alcuni casi, la vostra squadra potrebbe avere ulteriori strutture di directory sotto tests a causa della necessità di confezionare differenti suite di test in singoli file binari. E in questo caso, è necessario creare una nuova directory sotto sotto tests .

Per illustrare, qui è un tipico schema di directory per i componenti con un unico 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, si finirà per popolare il tests directory o la sottodirectory appena creata con file simili a ciò che è in native directory nel cambiamento Gerrit campione. Le sezioni seguenti spiegheranno in ulteriori dettagli di ciascun file.

Codice sorgente

Vedere la Ciao Mondo nativo di prova per un esempio.

Il codice sorgente annotato è elencato di seguito:

#include <gtest/gtest.h>

Il file di intestazione include per gtest. Si noti che la comprendono dipendenza file viene risolto automaticamente utilizzando BUILD_NATIVE_TEST nel makefile

#include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}

gtests sono scritti utilizzando TEST macro: il primo parametro è il nome banco di prova, e la seconda è nome del test; insieme al nome binario del test, formano la gerarchia sottostante quando vengono visualizzati 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, vedere la relativa documentazione:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

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 confezionamento. Nella maggior parte dei casi, l'opzione del file Blueprint basata su Soong è sufficiente. Vedere Configurazione di test semplice per i dettagli.

File di configurazione complesso

Per utilizzare Federazione dei Mercanti, invece, scrivere un file di configurazione di prova per il test harness di Android, Federazione dei Mercanti .

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

Crea e testa in locale

Per la maggior parte dei casi di uso comune, impiego Atest .

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