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 ile, Android kaynak ağacında minimum değişiklikle aynı test grubunu ön gönderme kontrollerine 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

Test eşleme grupları, test grubu ile test edilir. Test grubunun adı herhangi bir dize olabilir. Örneğin, presubmit, değişiklikler doğrulanırken çalıştırılacak bir test grubunun 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ı

Ticaret Federasyonu test düzeneğinin 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ı gerekir. Bu iki paketten biri kullanılabilir:

  • general-tests, cihaza özel özelliklere (ör. çoğu cihazda bulunmayan, satıcıya özel donanım) bağlı olmayan testler için kullanılır. Ç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 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/ bölümünde bulunur. Cihaza özel, yalnızca bir cihaza özgü özellikler için geçerlidir. Bu nedenle, 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ıştırılacak ş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, aşağıdaki örnekte gösterildiği gibi AndroidTest.xml içinde RootTargetPreparer ile belirtilmelidir:

    <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ğerinde ayarlayabilirsiniz. name alanında name sınıfının veya name test yönteminin kullanılamadığı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 oldukları 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 içe aktarmalara izin verir. Bu, iki TEST_MAPPING dosyanı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ılabilen 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 bölümüne bakın.

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_MAPPING mevcut çalışma dizinindeki (CWD) ve üst dizinlerdeki dosyalarda ön gönderme testleri çalıştırmanın en basit yoludur. Atest CWD'deki ve tüm üst dizinlerindeki TEST_MAPPING dosyasını bulup kullanır.

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ırın

Yalnızca cihaz gerektirmeyen ana makineye karşı yapılandırılmış testleri çalıştırmak için Atest'te --host seçeneğini kullanabilirsiniz. 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 dosyalarında test çalıştırmak istiyorsanız Atest'in bu testleri de dahil etmesini 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.

// biçiminde satır düzeyinde bir yorum ekleyerek TEST_MAPPING dosyasını, ayarın açıklamasını içerecek şekilde genişletebilirsiniz. ATest ve Ticaret Federasyonu, TEST_MAPPING öğesini yorum içermeyen geçerli bir JSON biçimine önceden işler. 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"
    }
  ]
}