Yeni GoogleTestleri Ekleme (GTestler)

Android platform geliştirmede yeniyseniz, ilgili tipik iş akışını göstermek için sıfırdan yepyeni bir GTest ikili dosyası (bazen "yerel" test olarak da adlandırılır) eklemenin bu eksiksiz örneğini yararlı bulabilirsiniz. C++ için GTest çerçevesi hakkında ek bilgi için, ek belgeler için GTest proje sitesine bakın.

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

Bir kaynak konumuna karar verme

Tipik olarak ekibiniz, kodu kontrol etmek için yerleşik bir yer düzenine ve test eklemek için yerlere zaten sahip olacaktır. Çoğu takımın tek bir git deposu vardır veya birini 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 eklediğiniz için, muhtemelen src bileşeninizin yanında tests dizini 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 başka dizin yapılarına sahip olabilir. Ve bu durumda, tests altında yeni bir alt dizin oluşturmanız gerekecek.

Örneklemek için, burada tek bir tests klasörüne 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)
      \-- src (test source)
          \-- foo_test.cpp
          \-- ...

ve işte birden çok test kaynağı dizinine sahip bileşenler için tipik bir dizin taslağı:

\
 <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ğindeki native dizinde bulunanlara benzer dosyalarla dolduracaksınız. Aşağıdaki bölümlerde her dosyanın daha ayrıntılı ayrıntıları açıklanacaktır.

Kaynak kodu

Bir ö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ı içerir. Dahil etme dosyası bağımlılığı, makefile'de 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 senaryosu adı ve ikincisi 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ünün, yapı sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatlarıyla yönlendirmek için bir yapılandırma dosyası 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 Trade Federation'ı kullanmak için Android'in test koşum takımı Trade Federation 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ı belirleyebilir.

Yerel olarak derleyin ve test edin

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

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