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. 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 sebelum melanjutkan.
Menentukan lokasi sumber
Biasanya, tim Anda sudah memiliki pola tempat yang ditetapkan untuk memeriksa 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 berada di <component source
root>, sebagian besar komponen memiliki folder src dan tests di bawahnya, dan beberapa
file tambahan seperti Android.mk (atau dipecah menjadi file .bp
tambahan).
Karena Anda menambahkan pengujian baru, Anda mungkin harus membuat
direktori tests di samping src komponen, 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 biner individual.
Dalam hal ini, Anda harus membuat subdirektori baru di bagian tests.
Sebagai ilustrasi, berikut adalah garis besar direktori standar 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 standar 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 mirip dengan yang ada di direktori native dalam contoh perubahan gerrit. Bagian di bawah ini akan menjelaskan
detail lebih lanjut dari setiap file.
Kode sumber
Lihat Hello World GTest untuk mengetahui contohnya.
Kode sumber untuk contoh tersebut dianotasi di sini:
#include <gtest/gtest.h>
Penyertaan file header untuk GTest. Dependensi file include akan otomatis diselesaikan menggunakan BUILD_NATIVE_TEST dalam makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTests 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 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 petunjuk paket. Dalam sebagian besar kasus, opsi file Blueprint berbasis Soong sudah cukup. Lihat Konfigurasi Pengujian Sederhana untuk mengetahui detailnya.
File konfigurasi kompleks
Sebagai gantinya, untuk menggunakan Trade Federation, tulis file konfigurasi pengujian untuk harness pengujian Android, Trade Federation.
Konfigurasi pengujian dapat menentukan opsi penyiapan perangkat khusus dan argumen default untuk menyediakan class pengujian.
Mem-build dan menguji secara lokal
Untuk kasus penggunaan yang paling umum, gunakan Atest.
Untuk kasus yang lebih kompleks yang memerlukan penyesuaian yang lebih berat, ikuti petunjuk instrumentasi.