Eşleştirmeyi Test Et

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

Test Haritalama Nedir?

Test Mapping, geliştiricilerin doğrudan Android kaynak ağacında gönderme ö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 , ilişkili dizinlerde ön gönderim testleri çalıştırmak için TEST_MAPPING dosyalarını kullanabilir. Test Eşleme ile, Android kaynak ağacında basit bir değişiklikle kontrolleri önceden göndermek için aynı test setini ekleyebilirsiniz.

Şu örneklere bakın:

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

İçe aktarma kullanan araçlar/dexter için TEST_MAPPING'e ön gönderme 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ımlama

Test Haritalama grupları testleri, bir test grubu aracılığıyla yapılır. Bir test grubunun adı herhangi bir dize olabilir. Örneğin, önceden gönderme , değişiklikleri doğrularken çalıştırılacak bir grup test için olabilir. Gönderim sonrası testler, değişiklikler birleştirildikten sonra yapıları doğrulamak için kullanılabilir.

Paketleme oluşturma komut dosyası kuralları

Trade Federation Test Harness'in belirli bir yapı için Test Mapping'in test modüllerini çalıştırabilmesi için, bu modüllerin Soong için test_suite setine veya Make için LOCAL_COMPATIBILITY_SUITE setinin şu iki süitten birine sahip olması gerekir:

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

Ö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 test paketinin içinde çalıştırılacak bir test için test:

• herhangi bir yapı sağlayıcısı olmamalıdır.
• örneğin test sırasında oluşturulan tüm geçici dosyaları silerek, tamamlandıktan sonra temizlemesi gerekir.
• sistem ayarlarını varsayılan veya orijinal değere değiştirin.
• belirli bir durumda bir cihaz varsaymamalıdır, örneğin, root hazır. Çoğu testin çalışması için kök ayrıcalığı gerekmez. Bir testin kök gerektirmesi gerekiyorsa, aşağıdaki örnekte olduğu gibi AndroidTest.xml RootTargetPreparer ile bunu 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, o dizinde veya alt dizinlerinden herhangi birinde herhangi bir dosyaya dokunulduğunda testlerin ön gönderme kontrollerinde çalışmasını sağlayacaktır.

Örnek takip

İşte örnek bir TEST_MAPPING dosyası (JSON biçimindedir ancak yorumlar desteklenir):

{
  "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 ayarlama

Yukarıdaki örnekte, presubmit ve postsubmit , her bir test grubunun adıdır. Test grupları hakkında daha fazla bilgi için Test gruplarını tanımlama bölümüne bakın.

Test modülünün adı veya Trade Federation entegrasyon test adı (test XML dosyasına giden kaynak yolu, örneğin uiautomator/uiautomator-demo ) name özniteliğ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 burada include-filter gibi seçenekleri kullanabilirsiniz. Bakınız ( dahil etme filtresi örnek kullanımı ).

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

file_patterns özniteliği, herhangi bir kaynak kod dosyasının (TEST_MAPPING dosyasını içeren dizine göre) göreli yolunu eşleştirmek için normal ifade dizelerinin bir listesini ayarlamanıza olanak tanır. Yukarıdaki örnekte, CtsWindowManagerDeviceTestCases testi, yalnızca herhangi bir Java dosyası, TEST_MAPPING dosyasının veya alt dizinlerinin aynı dizininde bulunan Window veya Activity ile başladığında, ön gönderimde çalışır. Bir JSON dosyasında oldukları için ters eğik çizgilerden \ kaçınılması gerekir.

imports özelliği, içeriği kopyalamadan testleri diğer TEST_MAPPING dosyalarına dahil etmenize olanak tanır. İçe aktarılan yolun üst dizinlerindeki TEST_MAPPING dosyalarının da dahil edileceğini unutmayın. Test Eşleme, iç içe içe aktarmalara izin verir; bu, iki TEST_MAPPING dosyasının birbirini içe aktarabileceği ve Test Eşleme'nin dahil edilen testleri uygun şekilde birleştirebileceği anlamına gelir.

options ö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 İşleme bölümüne bakın.

Atest ile test çalıştırma

Ö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önderme testleri çalıştırılır. Atest, ön gönderim (A ve B) için iki testi belirleyecek ve çalıştıracaktır.

Bu, geçerli çalışma dizinindeki (CWD) ve üst dizinlerdeki TEST_MAPPING dosyalarında ön gönderim testleri çalıştırmanın en basit yoludur. Atest, CWD ve tüm üst dizinlerindeki TEST_MAPPING dosyasını bulur ve kullanır.

Kaynak kodunu yapılandırma

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 :

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

src/project_1/TEST_MAPPING :

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

src/project_2/TEST_MAPPING :

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

Hedef dizinleri belirtme

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

atest --test-mapping src/project_1

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

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

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

Yalnızca cihaz gerektirmeyen testleri çalıştırma

Yalnızca hiçbir cihaz gerektirmeyen ana bilgisayara karşı yapılandırılmış testleri çalıştırmak için Atest için --host seçeneğini kullanabilirsiniz. Bu seçenek olmadan Atest, cihaz gerektirenler ve ana bilgisayar üzerinde çalışan ve cihaz gerektirmeyen testler olmak üzere her iki testi de çalıştırır. Testler iki ayrı süitte yürütülecektir.

atest [--test-mapping] --host

test gruplarını belirleme

Sen ATEST komuta test gruplarını belirtebilirsiniz. Aşağıdaki komut yalnızca bir testi (C) içeren dizin src / project_1, dosyalara ilişkin tüm postsubmit testler yapar.

Yoksa kullanabilirsiniz : Tüm bağımsız grubun tüm testler. Aşağıdaki komut dört deney (A, B, C, X) çalışır:

atest --test-mapping src/project_1:all

alt dizinleri dahil

Varsayılan olarak, ATEST ile TEST_MAPPING testler yürütmek sadece presubmit CWD'sindeki (veya verilen dizin) TEST_MAPPING dosyasında yapılandırılmış testler ve üst dizinleri çalışacaktır. Eğer alt dizinleri tüm TEST_MAPPING dosyalarında testlerini çalıştırmak istiyorsanız, opsiyon kullanma --include-subdir çok O testleri dahil etmek ATEST zorlamak için.

atest --include-subdir

Olmadan --include-subdir seçeneğiyle, ATEST ile tek bir test A. çalışacaktır --include-subdir ATEST iki testleri (A, B) çalışır, opsiyon.

Hat düzeyinde açıklama desteklenmektedir

Bir çizgi düzeyinde ekleyebilir // aşağıdaki ayarın açıklaması ile TEST_MAPPING dosyasını ayrıntılı hale getirmeye -Format yorumunu. ATest ve Ticaret Federasyonu Yorum içermeyen geçerli bir JSON biçimine TEST_MAPPING ön işlemeden edecektir. Sadece hat düzey, temiz ve kolay okunur JSON dosyasını tutmak için // -Format açıklama desteklenmektedir.

Misal:

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