Menambahkan GoogleTests (GTests) baru

Jika Anda baru mengenal pengembangan platform Android, Anda mungkin menemukan contoh lengkap penambahan biner GTest baru (terkadang juga disebut pengujian "native") dari awal yang berguna untuk menunjukkan alur kerja umum yang terlibat. Sebagai informasi tambahan tentang kerangka kerja GTest untuk C++, lihat project GTest untuk dokumentasi tambahan.

Panduan ini menggunakan Hello World GTest sebagai contoh. Sebaiknya baca seluruh kode untuk mendapatkan pemahaman kasar sebelum melanjutkan.

Menentukan lokasi sumber

Biasanya tim Anda sudah memiliki pola tempat untuk melakukan pemeriksaan dalam kode, dan tempat untuk menambahkan pengujian. Sebagian besar tim memiliki satu repositori git, atau berbagi dengan tim lain, tetapi memiliki subdirektori khusus yang berisi kode sumber komponen.

Dengan asumsi lokasi root untuk sumber komponen Anda adalah <component source root>, sebagian besar komponen memiliki folder src dan tests di bawahnya, dan beberapa file tambahan seperti Android.mk (atau dipecah menjadi .bp tambahan ).

Karena Anda menambahkan pengujian baru, Anda mungkin perlu membuat Direktori tests di samping komponen src Anda, dan isi dengan konten.

Dalam beberapa kasus, tim Anda mungkin memiliki struktur direktori lebih lanjut di tests karena Anda perlu mengemas rangkaian pengujian yang berbeda ke dalam biner individual. Dalam hal ini, Anda harus membuat subdirektori baru pada tests.

Sebagai ilustrasi, berikut adalah kerangka direktori umum untuk komponen dengan satu Folder 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
          \-- ...

dan berikut ini adalah kerangka direktori umum untuk komponen dengan beberapa sumber pengujian direktori:

\
 <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
      |       \-- ...
      \-- ...

Terlepas dari strukturnya, Anda pada akhirnya akan mengisi direktori tests atau sub direktori yang baru dibuat dengan file yang mirip dengan yang ada di native dalam perubahan gerrit sampel. Bagian di bawah ini akan menjelaskan detail lebih lanjut dari setiap file.

Kode sumber

Lihat Hello World GTest sebagai contoh.

Kode sumber untuk contoh tersebut dianotasi di sini:

#include <gtest/gtest.h>

File header disertakan untuk GTest. Dependensi file include secara otomatis diselesaikan dengan menggunakan BUILD_NATIVE_TEST dalam makefile.

#include <stdio.h>

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

GTest ditulis menggunakan makro TEST: parameter pertama adalah kasus pengujian dan yang kedua adalah nama pengujian. Bersama dengan nama biner uji, mereka membentuk hierarki berikut di dasbor hasil:

<test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...

Untuk informasi selengkapnya tentang cara menulis pengujian dengan GTest, lihat dokumentasi GTest

File konfigurasi sederhana

Setiap modul pengujian baru harus memiliki file konfigurasi untuk mengarahkan sistem build dengan metadata modul, dependensi waktu kompilasi, dan paket petunjuk. Pada umumnya, opsi file {i>Blueprint <i}berbasis Soong memadai. Lihat Konfigurasi Pengujian Sederhana untuk mengetahui detailnya.

File konfigurasi kompleks

Untuk menggunakan Trade Federation, tulis konfigurasi pengujian file untuk test harness Android, Trade Federation.

Konfigurasi pengujian dapat menentukan opsi penyiapan perangkat khusus dan setelan default argumen untuk menyediakan class pengujian.

Membangun dan menguji secara lokal

Untuk kasus penggunaan yang paling umum, gunakan Atest.

Untuk kasus lebih kompleks yang memerlukan penyesuaian lebih berat, ikuti petunjuk instrumentasi.