Test eşleme

Bu makalede, test eşleme hakkında kısa bir giriş ve Android Açık Kaynak Projesi'nde (AOSP) testleri yapılandırmaya nasıl başlayacağınızla ilgili bir açıklama yer almaktadır.

Test eşleme hakkında

Test eşleme, geliştiricilerin doğrudan Android kaynak ağacında gönderme öncesi ve gönderme sonrası test kuralları oluşturmasına olanak tanıyan Gerrit tabanlı bir yaklaşımdır. Test edilecek dallar ve cihazlarla ilgili kararlar test altyapısına bırakılır. Test eşleme tanımları, herhangi bir kaynak dizine yerleştirebileceğiniz TEST_MAPPING adlı JSON dosyalarıdır.

Atest, ilişkili dizinlerde gönderme öncesi testleri çalıştırmak için TEST_MAPPING dosyalarını kullanabilir. Test eşleme sayesinde, Android kaynak ağacında minimum değişiklikle aynı test grubunu gönderme öncesi kontrollere ekleyebilirsiniz.

Şu örneklere bakın:

Test eşleme, test yürütme ve sonuç raporlama için Ticaret Federasyonu (TF) test düzeneğini kullanır.

Test gruplarını tanımlama

Eşleme gruplarını test grubuyla test edin. Test grubunun adı herhangi bir dize olabilir. Örneğin, presubmit, değişiklikler doğrulanırken çalıştırılacak bir grup testin adı olabilir. Gönderme sonrası ise değişiklikler birleştirildikten sonra derlemeleri doğrulamak için kullanılan testler olabilir.

Paket oluşturma komut dosyası kuralları

Trade Federation test harness'ın belirli bir derleme için test modüllerini çalıştırması amacıyla bu modüllerin, Soong için test_suites veya Make için LOCAL_COMPATIBILITY_SUITE ayarlanmış olması ve bu iki paketten birine ait olması gerekir:

  • general-tests, cihaza özgü özelliklere (ör. çoğu cihazda bulunmayan, satıcıya özgü donanım) bağlı olmayan testler içindir. Çoğu test, tek bir ABI veya bit sayısı ya da HWASan gibi donanım özelliklerine özgü olsa bile (her ABI için ayrı bir test_suites hedefi vardır) ve bir cihazda çalışması gerekse bile general-tests paketinde olmalıdır.
  • device-tests, cihaza özel özelliklere bağlı testler içindir. Bu testler genellikle vendor/ altında bulunur. Cihaza özel, yalnızca bir cihaza özgü özellikleri ifade eder. Bu nedenle, bu durum JUnit testlerinin yanı sıra GTest testleri için de geçerlidir (ABI'ye özgü olsalar bile genellikle general-tests olarak işaretlenmelidir).

Ö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 paketi içinde çalışması için testin:

  • Derleme sağlayıcısı olmamalıdır.
  • İşlem bittikten sonra temizlik yapmalıdır. Örneğin, test sırasında oluşturulan geçici dosyaları silmelidir.
  • Sistem ayarları varsayılan veya orijinal değere değiştirilmelidir.

  • Bir cihazın belirli bir durumda olduğunu (ör. root erişimine hazır) varsaymamalıdır. Çoğu testin çalıştırılması için kök ayrıcalığı gerekmez. Bir testin root erişimi gerektirmesi durumunda, AndroidTest.xml içinde RootTargetPreparer ile belirtilmesi gerekir. Örneğin:

    <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Test eşleme dosyaları oluşturma

Test kapsamı gerektiren dizin için örneğe benzeyen bir TEST_MAPPING JSON dosyası ekleyin. Bu kurallar, söz konusu dizinde veya alt dizinlerinden herhangi birinde dosyalara dokunulduğunda testlerin ön gönderme kontrollerinde çalıştırılmasını sağlar.

Örnekleri inceleyin

Burada bir örnek TEST_MAPPING dosyası (JSON biçimindedir ancak yorumlar desteklenir) verilmiştir:

{
  "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": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Özellikleri ayarlama

Ö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 başlıklı makaleyi inceleyin.

Test modülünün veya Trade Federation entegrasyon testinin adını (test XML dosyasının kaynak yolu, örneğin, uiautomator/uiautomator-demo) name özelliğinin değerine ayarlayabilirsiniz. name alanında name sınıfının veya name test yönteminin kullanılamayacağını unutmayın. Çalıştırılacak testleri daraltmak için include-filter gibi seçenekleri kullanın. include-filterÖrnek kullanıma bakın.

Bir testin host ayarı, testin ana makinede çalışan cihazsız bir test olup olmadığını gösterir. Varsayılan değer false'dır. Bu, testin çalışması için bir cihaz gerektiği anlamına gelir. Desteklenen test türleri, GTest ikilileri için HostGTest, JUnit testleri için ise HostTest'dır.

file_patterns özelliği, herhangi bir kaynak kodu dosyasının göreli yolunu (TEST_MAPPING dosyasını içeren dizine göre) eşleştirmek için bir normal ifade dizeleri listesi ayarlamanıza olanak tanır. Örnekte, CtsWindowManagerDeviceTestCases testi yalnızca bir Java dosyası Window veya Activity ile başladığında ve bu dosya TEST_MAPPING dosyasıyla aynı dizinde ya da alt dizinlerinden birinde bulunduğunda ön gönderme sırasında çalıştırılır. Ters eğik çizgiler (\), JSON dosyasında bulundukları için kaçış karakteri olarak kullanılmalıdır.

imports özelliği, içeriği kopyalamadan diğer TEST_MAPPING dosyalarına test eklemenize olanak tanır. İçe aktarılan yolun üst dizinlerindeki TEST_MAPPING dosyaları da dahil edilir. Test eşleme, iç içe aktarmalara izin verir. Bu, iki TEST_MAPPING dosyasının birbirini içe aktarabileceği ve test eşlemenin dahil edilen testleri birleştirebileceği anlamına gelir.

options özelliği, ek Tradefed komut satırı seçeneklerini içerir.

Belirli bir test için kullanılabilir seçeneklerin tam listesini almak üzere şu komutu çalıştırın:

tradefed.sh run commandAndExit [test_module] --help

Seçeneklerin nasıl çalıştığı hakkında daha fazla bilgi için Tradefed'de seçenek işleme başlıklı makaleyi inceleyin.

Atest ile testler yapma

Gönderme öncesi 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

Mevcut dizinin ve üst dizinlerinin TEST_MAPPING dosyalarında yapılandırılan tüm gönderme öncesi testler çalıştırılır. Atest, ön gönderme için iki test (A ve B) bulur ve çalıştırır.

Bu, TEST_MAPPINGmevcut çalışma dizinindeki (CWD) ve üst dizinlerdeki dosyalardaTEST_MAPPING ön gönderme testleri çalıştırmanın en basit yoludur. Atest locates and uses the TEST_MAPPING file in CWD and all of its parent directories.

Kaynak kodunu yapılandırma

Bu örnekte, kaynak ağacında TEST_MAPPING dosyalarını nasıl yapılandırabileceğiniz gösterilmektedir:

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, TEST_MAPPING dosyalarında çalıştırmak için hedef dizin belirtebilirsiniz. Aşağıdaki komut iki test (A, B) çalıştırır:

atest --test-mapping src/project_1

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

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

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

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

Atest için --host seçeneğini kullanarak yalnızca cihaz gerektirmeyen ana makineye karşı yapılandırılmış testleri çalıştırabilirsiniz. Bu seçenek olmadan Atest, hem cihaz gerektiren hem de cihaz gerektirmeyen bir ana makinede çalışan testleri çalıştırır. Testler iki ayrı pakette çalıştırılır:

atest [--test-mapping] --host

Test gruplarını belirleme

Atest komutunda test gruplarını belirtebilirsiniz. Aşağıdaki komut, yalnızca bir test (C) içeren src/project_1 dizinindeki dosyalarla ilgili tüm postsubmit testlerini çalıştırır.

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

atest --test-mapping src/project_1:all

Alt dizinleri dahil et

Varsayılan olarak, TEST_MAPPING içinde Atest ile test çalıştırmak yalnızca CWD'deki (veya verilen dizindeki) TEST_MAPPING dosyasında ve üst dizinlerinde yapılandırılan göndermeden önce testlerini çalıştırır. Alt dizinlerdeki tüm TEST_MAPPING dosyalarda test çalıştırmak istiyorsanız Atest'in bu testleri de içermesini 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.

Ayarı açıklayan bir açıklama ekleyerek TEST_MAPPING dosyayı ayrıntılandırmak için satır düzeyinde // biçiminde yorum ekleyebilirsiniz. ATest ve Ticaret Federasyonu, TEST_MAPPING öğesini yorum içermeyen geçerli bir JSON biçimine dönüştürür. JSON dosyasının temiz kalması için yalnızca satır düzeyinde // biçim yorumu desteklenir.

Örnek:

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