Test eşlemesi

Bu, test eşlemenin kısa bir tanıtımıdır ve Android Açık Kaynak Projesi'nde (AOSP) testleri kolayca yapılandırmaya nasıl başlanacağının bir açıklamasıdır.

Test eşleme hakkında

Test eşleme, geliştiricilerin doğrudan Android kaynak ağacında test öncesi ve sonrası test kuralları oluşturmasına ve test edilecek dalların ve cihazların kararlarını test altyapısının kendisine bırakmasına olanak tanıyan Gerrit tabanlı bir yaklaşımdır. Test eşleme tanımları, herhangi bir kaynak dizine yerleştirilebilen TEST_MAPPING adlı JSON dosyalarıdır.

Atest, ilgili dizinlerde ön gönderim testleri çalıştırmak için TEST_MAPPING dosyalarını kullanabilir. Test eşlemeyle, Android kaynak ağacında basit bir değişiklikle aynı test kümesini kontrolleri önceden göndermek için ekleyebilirsiniz.

Şu örneklere bakın:

Services.core için TEST_MAPPING'e ön gönderim testleri ekleyin

İçe aktarmaları kullanan araçlar/dexter için TEST_MAPPING'e ön gönderim testleri ekleyin

Test eşleme, testlerin yürütülmesi ve sonuçların raporlanması için Ticaret Federasyonu (TF) Test Donanımına dayanır.

Test gruplarını tanımlayın

Eşleme grup testlerini bir test grubu aracılığıyla test edin. Bir test grubunun adı herhangi bir dize olabilir. Örneğin, ön gönderim, değişiklikleri doğrularken çalıştırılacak bir grup test için olabilir. Değişiklikler birleştirildikten sonra derlemeleri doğrulamak için gönderim sonrası testler kullanılabilir.

Paket oluşturma komut dosyası kuralları

Ticaret Federasyonu Test Koşumunun belirli bir yapı için test eşlemesinin test modüllerini çalıştırabilmesi için, bu modüllerin Soong için test_suite ayarına sahip olması veya Make için şu iki paketten birine LOCAL_COMPATIBILITY_SUITE ayarına sahip olması gerekir:

  • genel testler - cihaza özgü işlevselliğe bağlı olmayan testler (çoğu cihazın sahip olmadığı satıcıya özel donanım gibi). Testlerin çoğu, bir ABI'ye veya bitliğe veya HWASan gibi donanım özelliklerine (her ABI için ayrı bir test_suites hedefi vardır) özgü olsa ve bir cihazda çalıştırılmaları gerekse bile genel testler paketinde olmalıdır.
  • cihaz testleri - cihaza özgü işlevselliğe bağlı testler. Tipik olarak bu testler vendor/ altında bulunur. "Cihaza özgü", diğer cihazların sahip olabileceği veya olmayabileceği ABI veya SoC işlevselliğini değil, yalnızca bir cihaza özgü işlevselliği ifade ettiğinden, bu, GTest yerel testleri kadar JUnit testleri için de her bit için geçerlidir (ki bu genellikle gerekir) ABI'ye özgü olsalar bile general-tests olabilir).

Örnekler:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Testleri bir test paketinde çalışacak şekilde yapılandırma

Bir testin test paketinin içinde çalıştırılması için test:

  • herhangi bir yapı sağlayıcısı olmamalıdır.
  • tamamlandıktan sonra, örneğin test sırasında oluşturulan geçici dosyaları silerek temizlemelidir.
  • sistem ayarlarını varsayılan veya orijinal değere değiştirin.
  • bir cihazın belirli bir durumda olduğunu (örneğin, root için hazır) varsaymamalıdır. Çoğu testin çalıştırılması için root ayrıcalığı gerekmez. Bir testin root gerektirmesi gerekiyorsa, bunu aşağıdaki örnekte olduğu gibi AndroidTest.xml dosyasında RootTargetPreparer ile belirtmelidir:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Test eşleme dosyaları oluşturma

Test kapsamı gerektiren dizin için aşağıdaki örneğe benzeyen bir TEST_MAPPING JSON dosyası eklemeniz yeterlidir. Bu kurallar, söz konusu dizindeki veya alt dizinlerinden herhangi birinde herhangi bir dosyaya dokunulduğunda testlerin gönderim öncesi kontrollerde çalışmasını sağlayacaktır.

Bir örneği takip edin

Örnek bir TEST_MAPPING dosyası aşağıda verilmiştir (JSON formatındadır ancak yorumlar desteklenmektedir):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Nitelikleri ayarla

Yukarıdaki örnekte, presubmit ve postsubmit her test grubunun adıdır. Test grupları hakkında daha fazla bilgi için bkz. Test gruplarını tanımlama .

Test modülünün adı veya Ticaret Federasyonu entegrasyon test adı (test XML dosyasının kaynak yolu, örneğin uiautomator/uiautomator-demo ), name özelliğinin değerinde ayarlanabilir. Ad alanının sınıf name veya test yöntemi name kullanamayacağını unutmayın. Çalıştırılacak testleri daraltmak için buradaki include-filter gibi seçenekleri kullanabilirsiniz. Bkz. ( içerme filtresi örnek kullanımı ).

Bir testin ana bilgisayar ayarı, testin ana bilgisayarda çalışan cihazsız bir test olup olmadığını gösterir. Varsayılan değer false olup, testin çalışması için bir cihazın gerekli olduğu anlamına gelir. Desteklenen test türleri GTest ikili dosyaları için HostGTest ve JUnit testleri için HostTest'tir .

file_patterns niteliği, herhangi bir kaynak kod dosyasının (TEST_MAPPING dosyasını içeren dizine göre) göreceli yolunu eşleştirmek için normal ifade dizelerinin bir listesini ayarlamanıza olanak tanır. Yukarıdaki örnekte, test CtsWindowManagerDeviceTestCases yalnızca TEST_MAPPING dosyasının aynı dizininde veya alt dizinlerinden herhangi birinde bulunan Window veya Activity ile başlayan herhangi bir Java dosyası değiştirildiğinde ön gönderimde çalışacaktır. Ters eğik çizgilerin \ JSON dosyasında olduğu gibi kaçılması gerekir.

Imports özelliği, içeriği kopyalamadan testleri diğer TEST_MAPPING dosyalarına eklemenizi sağlar. İçe aktarılan yolun üst dizinlerindeki TEST_MAPPING dosyalarının da dahil edileceğini unutmayın. Test eşlemesi iç içe içe aktarmaya izin verir; bu, iki TEST_MAPPING dosyasının birbirini içe aktarabileceği ve Test eşlemenin dahil edilen testleri düzgün şekilde birleştirebileceği anlamına gelir.

Seçenekler özelliği ek TradeFed komut satırı seçeneklerini içerir.

Belirli bir test için mevcut seçeneklerin tam listesini almak için şunu çalıştırın:

tradefed.sh run commandAndExit [test_module] --help

Opsiyonların nasıl çalıştığı hakkında daha fazla ayrıntı için TradeFed Opsiyon İşlemleri'ne bakın.

Atest ile testleri çalıştırın

Ön gönderim test kurallarını yerel olarak yürütmek için:

  1. TEST_MAPPING dosyasını içeren dizine gidin.
  2. Komutu çalıştırın:
atest

Geçerli dizinin ve üst dizinlerinin TEST_MAPPING dosyalarında yapılandırılan tüm ön gönderim testleri çalıştırılır. Atest, ön gönderim için iki testi (A ve B) bulup çalıştıracaktır.

Bu, geçerli çalışma dizinindeki (CWD) ve üst dizinlerdeki TEST_MAPPING dosyalarındaki ön gönderim testlerini çalıştırmanın en basit yoludur. Atest, CWD'de ve tüm üst dizinlerinde TEST_MAPPING dosyasını bulacak ve kullanacaktır.

Yapı kaynak kodu

Aşağıdaki örnek, TEST_MAPPING dosyalarının kaynak ağaçta nasıl yapılandırılabileceğini gösterir.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

src/TEST_MAPPING içeriği:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

src/project_1/TEST_MAPPING içeriği:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

src/project_2/TEST_MAPPING içeriği:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Hedef dizinleri belirtin

Testleri o dizindeki TEST_MAPPING dosyalarında çalıştırmak için bir hedef dizin belirleyebilirsiniz. Aşağıdaki komut iki test (A, B) çalıştıracaktır.

atest --test-mapping src/project_1

Gönderim sonrası test kurallarını çalıştır

Bu komutu ayrıca src_path (varsayılanı CWD'dir) ve üst dizinlerinde TEST_MAPPING'de tanımlanan gönderim sonrası test kurallarını çalıştırmak için de kullanabilirsiniz:

atest [--test-mapping] [src_path]:postsubmit

Yalnızca cihaz gerektirmeyen testleri çalıştırın

Atest için --host seçeneğini yalnızca ana makineye karşı yapılandırılan ve cihaz gerektirmeyen testleri çalıştırmak için kullanabilirsiniz. Bu seçenek olmadan Atest, cihaz gerektiren testler ve ana bilgisayarda çalışan ve cihaz gerektirmeyen testler olmak üzere her iki testi de çalıştıracaktır. Testler iki ayrı süitte gerçekleştirilecektir.

atest [--test-mapping] --host

Test gruplarını tanımlayın

Atest komutunda test gruplarını belirleyebilirsiniz. Aşağıdaki komut, yalnızca bir test (C) içeren src/project_1 dizinindeki dosyalarla ilgili tüm gönderim sonrası testleri çalıştıracaktır.

Veya gruptan bağımsız olarak tüm testleri çalıştırmak için :all komutunu kullanabilirsiniz. Aşağıdaki komut dört testi çalıştırır (A, B, C, X):

atest --test-mapping src/project_1:all

Alt dizinleri dahil et

Varsayılan olarak, TEST_MAPPING'de testleri Atest ile çalıştırmak yalnızca CWD'deki (veya belirli bir dizindeki) ve onun üst dizinlerindeki TEST_MAPPING dosyasında yapılandırılan ön gönderim testlerini çalıştıracaktır. Alt dizinlerdeki tüm TEST_MAPPING dosyalarında testler çalıştırmak istiyorsanız, Atest'i bu testleri de dahil etmeye zorlamak için --include-subdir seçeneğini kullanın.

atest --include-subdir

--include-subdir seçeneği olmadan Atest yalnızca A testini çalıştırır. --include-subdir seçeneğiyle Atest iki test (A, B) çalıştırır.

Satır düzeyinde yorum desteklenir

TEST_MAPPING dosyasını aşağıdaki ayarın açıklamasıyla detaylandırmak için satır düzeyinde // biçimli bir yorum ekleyebilirsiniz. ATest ve Ticaret Federasyonu, TEST_MAPPING'i yorum yapmadan geçerli bir JSON formatına göre ön işleme tabi tutacaktır. JSON dosyasını temiz ve okunması kolay tutmak için yalnızca satır düzeyinde // -format yorumu desteklenir.

Örnek:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}