Yeni Bir Yerel Test Örneği Ekleme

Android platform geliştirmede yeniyseniz, ilgili tipik iş akışını göstermek için sıfırdan yeni bir yerel test eklemenin bu eksiksiz örneğini faydalı bulabilirsiniz. Ayrıca, C ++ için gtest çerçevesine de aşina değilseniz, ek belgeler için lütfen gtest proje sitesini inceleyin .

Bu kılavuz, örnek olarak hizmet etmek için aşağıdaki testi kullanır:

Merhaba Dünya Yerel Testi

Devam etmeden önce kaba bir izlenim elde etmek için önce koda göz atmanız önerilir.

Bir kaynak konuma karar vermek

Tipik olarak ekibiniz, kodu kontrol etmek için önceden belirlenmiş bir yer kalıbına ve testlerin ekleneceği yerlere sahip olacaktır. Çoğu ekibin 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.

Eğer bileşen kaynağı için kök konumunu varsayılırsa olan <component source root> , en bileşenleri var src ve tests gibi bunun altında klasörleri ve bazı ek dosyalar Android.mk (veya ek bölünmüştür .bp dosyaları).

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

Bazı durumlarda, farklı test takımlarını ayrı ikili dosyalar halinde paketlemeniz gerektiğinden, 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 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 çok test kaynak 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ğindeki native dizinde bulunanlara benzer dosyalarla dolduracaksınız. Aşağıdaki bölümler, her dosyanın daha ayrıntılı olarak açıklanacaktır.

Kaynak kodu

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

Ek açıklamalı kaynak kodu aşağıda listelenmiştir:

#include <gtest/gtest.h>

Başlık dosyası gtest için içerir. BUILD_NATIVE_TEST dosyası bağımlılığının makefile'da BUILD_NATIVE_TEST kullanılarak otomatik olarak çözüldüğünü BUILD_NATIVE_TEST .

#include <stdio.h>

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

gtest'ler TEST makrosu kullanılarak yazılır: ilk parametre test olayı adı ve ikincisi test adıdır; test ikili adı ile birlikte, sonuç panosunda görselleştirildiklerinde 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 belgelerine bakın:

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

Basit konfigürasyon dosyası

Her yeni test modülünün, yapı sistemini modül meta verileri, derleme zamanı bağımlılıkları ve paketleme talimatları ile yönlendirmek için bir yapılandırma dosyasına sahip olması gerekir. Çoğu durumda, Soong tabanlı Blueprint dosya 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 koşum takımı olan Ticaret Federasyonu için bir test yapılandırma dosyası yazın.

Test yapılandırması, test sınıfını sağlamak için özel cihaz kurulum seçeneklerini ve varsayılan bağımsız değişkenleri belirtebilir.

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.