Yeni GoogleTest'leri (GTest'ler) ekle

Android platformu geliştirmede yeniyseniz, sıfırdan yepyeni bir GTest ikili programı (bazen "yerel" test olarak da adlandırılır) eklemeye ilişkin bu tam örneği, ilgili tipik iş akışını göstermek için yararlı bulabilirsiniz. C++ için GTest çerçevesi hakkında ek bilgi için ek belgelere yönelik GTest proje sitesine bakın.

Bu kılavuzda örnek olarak Hello World GTest kullanılmaktadır. Devam etmeden önce kabaca anlamak için kodu baştan sona okumanızı öneririz.

Kaynak konumuna karar verin

Tipik olarak ekibiniz, kodun teslim edileceği yerler ve testlerin ekleneceği yerler konusunda önceden belirlenmiş bir modele sahip olacaktır. Çoğu ekibin tek bir git deposu vardır veya bir tanesini diğer ekiplerle paylaşır ancak bileşen kaynak kodunu içeren özel bir alt dizine sahiptir.

Bileşen kaynağınızın kök konumunun <component source root> konumunda olduğunu varsayarsak, çoğu bileşenin altında src ve tests klasörleri ve Android.mk (veya ek .bp dosyalarına bölünmüş) gibi bazı ek dosyalar bulunur.

Yepyeni bir test ekleyeceğiniz için muhtemelen src bileşeninizin yanında tests dizinini oluşturmanız ve onu içerikle doldurmanız gerekecektir.

Bazı durumlarda, farklı test paketlerini ayrı ikili dosyalar halinde paketleme ihtiyacı nedeniyle ekibiniz, tests altında daha fazla dizin yapısına sahip olabilir. Bu durumda, tests altında yeni bir alt dizin oluşturmanız gerekecektir.

Örnek olarak, tek bir tests klasörüne sahip bileşenler için tipik bir dizin taslağı aşağıda verilmiştir:

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

ve burada birden fazla test kaynağı dizinine sahip bileşenler için tipik bir dizin taslağı verilmiştir:

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

Yapıdan bağımsız olarak, tests dizinini veya yeni oluşturulan alt dizini, örnek gerrit değişikliğinde native dizinde bulunanlara benzer dosyalarla dolduracaksınız. Aşağıdaki bölümlerde her dosyaya ilişkin daha ayrıntılı bilgi açıklanacaktır.

Kaynak kodu

Örnek için Hello World GTest'e bakın.

Bu örneğin kaynak kodu burada açıklanmıştır:

#include <gtest/gtest.h>

GTest için başlık dosyası dahildir. Dahil etme dosyası bağımlılığı, makefile'da BUILD_NATIVE_TEST kullanılarak otomatik olarak çözülür.

#include <stdio.h>

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

GTest'ler TEST makrosu kullanılarak yazılır: ilk parametre test senaryosunun adı, ikincisi ise test adıdır. Test ikili adıyla birlikte sonuç panosunda aşağıdaki hiyerarşiyi oluştururlar:

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

GTest ile test yazma hakkında daha fazla bilgi için GTest belgelerine bakın.

Basit yapılandırma dosyası

Her yeni test modülü, derleme sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirecek bir yapılandırma dosyasına sahip olmalıdır. Çoğu durumda Soong tabanlı Blueprint dosyası seçeneği yeterlidir. Ayrıntılar için Basit Test Yapılandırması'na bakın.

Karmaşık yapılandırma dosyası

Bunun yerine Ticaret Federasyonu'nu kullanmak için, Android'in test donanımı olan Ticaret Federasyonu için bir test yapılandırma dosyası yazın.

Test konfigürasyonu, test sınıfını sağlamak için özel cihaz kurulum seçeneklerini ve varsayılan argümanları belirtebilir.

Yerel olarak derleyin ve test edin

En yaygın kullanım durumları için Atest'i kullanın.

Daha yoğun özelleştirme gerektiren daha karmaşık durumlar için enstrümantasyon talimatlarını izleyin.