Jika Anda baru dalam pengembangan platform Android, Anda dapat menemukan contoh lengkap ini tentang cara menambahkan biner GTest baru (terkadang juga disebut pengujian "native") dari awal yang berguna untuk mendemonstrasikan alur kerja umum yang terlibat. Untuk informasi tambahan tentang framework GTest untuk C++, lihat situs project GTest untuk dokumentasi tambahan.
Panduan ini menggunakan Hello World GTest sebagai contoh. Sebaiknya baca kode untuk mendapatkan pemahaman kasar tentangnya sebelum Anda melanjutkan.
Tentukan lokasi sumber
Biasanya, tim Anda sudah memiliki pola tempat yang ditetapkan untuk diperiksa dalam kode, dan tempat untuk menambahkan pengujian. Sebagian besar tim memiliki satu repositori git, atau membagikannya dengan tim lain, tetapi memiliki subdirektori khusus yang berisi kode sumber komponen.
Dengan asumsi lokasi root untuk sumber komponen Anda berada di <component source
root>
, sebagian besar komponen memiliki folder src
dan tests
di dalamnya, dan beberapa
file tambahan seperti Android.mk
(atau dibagi menjadi file .bp
tambahan).
Karena Anda menambahkan pengujian yang benar-benar baru, Anda mungkin perlu membuat direktori tests
di samping komponen src
, dan mengisinya dengan konten.
Dalam beberapa kasus, tim Anda mungkin memiliki struktur direktori lebih lanjut di bawah tests
karena perlu mengemas rangkaian pengujian yang berbeda ke dalam masing-masing biner.
Dalam hal ini, Anda harus membuat subdirektori baru di tests
.
Sebagai ilustrasi, berikut adalah garis besar 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 adalah garis besar direktori umum untuk komponen dengan beberapa direktori sumber pengujian:
\
<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 akan mengisi direktori tests
atau subdirektori yang baru dibuat dengan file yang serupa dengan yang ada di direktori native
dalam perubahan gerrit contoh. Bagian di bawah ini akan menjelaskan setiap file secara lebih mendetail.
Kode sumber
Lihat Hello World GTest untuk mengetahui contohnya.
Kode sumber untuk contoh tersebut diberi anotasi di sini:
#include <gtest/gtest.h>
Penyertaan file header untuk GTest. Dependensi file include diselesaikan secara otomatis menggunakan BUILD_NATIVE_TEST
dalam makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest ditulis menggunakan makro TEST
: parameter pertama adalah nama kasus pengujian, dan parameter kedua adalah nama pengujian. Bersama dengan nama biner pengujian, keduanya 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 mengetahui informasi selengkapnya tentang penulisan 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 petunjuk pengemasan. Dalam sebagian besar kasus, opsi file Blueprint berbasis Soong sudah cukup. Lihat Konfigurasi Pengujian Sederhana untuk mengetahui detailnya.
File konfigurasi yang kompleks
Untuk menggunakan Trade Federation, tulis file konfigurasi pengujian untuk platform pengujian Android, Trade Federation.
Konfigurasi pengujian dapat menentukan opsi penyiapan perangkat khusus dan argumen default untuk menyediakan class pengujian.
Membuat dan menguji secara lokal
Untuk kasus penggunaan yang paling umum, gunakan Atest.
Untuk kasus yang lebih kompleks yang memerlukan penyesuaian lebih berat, ikuti petunjuk instrumentasi.