Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Menambahkan GoogleTests Baru (GTests)

Jika Anda baru dalam pengembangan platform Android, Anda mungkin menemukan contoh lengkap penambahan biner GTest baru (juga terkadang disebut pengujian "asli") dari awal yang berguna untuk mendemonstrasikan alur kerja tipikal yang terlibat. Untuk informasi tambahan tentang kerangka kerja GTest untuk C++, lihat situs proyek GTest untuk dokumentasi tambahan.

Panduan ini menggunakan Hello World GTest sebagai contoh. Kami merekomendasikan membaca kode untuk mendapatkan pemahaman kasar sebelum Anda melanjutkan.

Menentukan lokasi sumber

Biasanya tim Anda sudah memiliki pola tempat untuk check-in kode, dan tempat untuk menambahkan tes. Sebagian besar tim memiliki repositori git tunggal, atau berbagi satu dengan tim lain tetapi memiliki sub direktori 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 tes baru, Anda mungkin perlu membuat direktori tests di sebelah komponen Anda src , dan mengisinya dengan konten.

Dalam beberapa kasus, tim Anda mungkin memiliki struktur direktori lebih lanjut yang sedang tests karena kebutuhan untuk mengemas rangkaian pengujian yang berbeda ke dalam binari individual. Dan dalam hal ini, Anda harus membuat sub direktori baru di bawah 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 inilah garis besar direktori tipikal 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 berakhir mengisi direktori tests atau sub direktori yang baru dibuat dengan file yang mirip dengan apa 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 sebagai contoh.

Kode sumber untuk contoh itu dijelaskan di sini:

#include <gtest/gtest.h>

File header termasuk untuk GTest. Ketergantungan sertakan file secara otomatis diselesaikan dengan menggunakan BUILD_NATIVE_TEST di makefile.

#include <stdio.h>

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

GTests ditulis menggunakan makro TEST : parameter pertama adalah nama test case, dan yang kedua adalah nama test. Bersama dengan nama biner pengujian, 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 lebih lanjut tentang tes menulis dengan GTest, lihat dokumentasi GTest

File konfigurasi sederhana

Setiap modul pengujian baru harus memiliki file konfigurasi untuk mengarahkan sistem pembangunan dengan metadata modul, dependensi waktu kompilasi, dan instruksi pengemasan. Dalam kebanyakan kasus, opsi file Blueprint berbasis Soong sudah cukup. Lihat Konfigurasi Tes Sederhana untuk detailnya.

File konfigurasi kompleks

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

Konfigurasi pengujian dapat menentukan opsi pengaturan perangkat khusus dan argumen default untuk memasok kelas pengujian.

Bangun dan uji secara lokal

Untuk kasus penggunaan yang paling umum, gunakan Atest .

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