Google berkomitmen untuk memajukan ekuitas ras untuk komunitas kulit hitam. Lihat bagaimana.
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Menambahkan Contoh Uji Asli Baru

Jika Anda baru dalam pengembangan platform Android, Anda mungkin menemukan contoh lengkap ini menambahkan tes asli baru dari awal yang berguna untuk menunjukkan alur kerja khas yang terlibat. Selain itu, jika Anda juga tidak terbiasa dengan kerangka kerja gtest untuk C ++, silakan tinjau situs proyek gtest untuk dokumentasi tambahan.

Panduan ini menggunakan tes tindak untuk dijadikan sampel:

Hello World Native Test

Disarankan untuk menelusuri kode terlebih dahulu untuk mendapatkan kesan kasar sebelum melanjutkan.

Menentukan lokasi sumber

Biasanya tim Anda sudah memiliki pola tempat untuk memeriksa kode masuk, dan tempat untuk menambahkan tes. Sebagian besar tim memiliki repositori git tunggal, atau membagikannya 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 sebelah src komponen Anda, dan mengisinya dengan konten.

Dalam beberapa kasus, tim Anda mungkin memiliki struktur direktori lebih lanjut yang sedang tests karena kebutuhan untuk mengemas suite tes yang berbeda ke dalam masing-masing biner. Dan dalam hal ini, Anda harus membuat sub direktori baru yang sedang tests .

Untuk mengilustrasikannya, inilah garis besar direktori tipikal untuk komponen dengan folder tests tunggal:

 \
 <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 perubahan sampel gerrit. Bagian di bawah ini akan menjelaskan secara lebih rinci setiap file.

Kode sumber

Lihat Hello World Native Test sebagai contoh.

Kode sumber beranotasi tercantum di bawah ini:

 #include <gtest/gtest.h>
 

File header termasuk untuk gtest. Perhatikan bahwa ketergantungan file sertakan diselesaikan secara otomatis dengan menggunakan BUILD_NATIVE_TEST di makefile

 #include <stdio.h>

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

gtests ditulis dengan menggunakan TEST macro: parameter pertama adalah nama kasus uji, dan yang kedua adalah nama tes; bersama dengan nama uji biner, mereka membentuk hierarki di bawah ini ketika divisualisasikan 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 dokumentasinya:

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

File konfigurasi sederhana

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

File konfigurasi yang kompleks

Untuk menggunakan Federasi Dagang sebagai gantinya, tulis file konfigurasi pengujian untuk memanfaatkan uji Android, Federasi Dagang .

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

Bangun dan uji secara lokal

Untuk kasus penggunaan yang paling umum, gunakan Atest .

Untuk kasus yang lebih kompleks yang membutuhkan penyesuaian lebih berat, ikuti instruksi instrumentasi .