Eşlemeyi test et

Bu makalede, test eşlemeye dair kısa bir giriş ve Android Open Source Project'te (AOSP) testleri yapılandırmaya nasıl başlayacağınıza dair bir açıklama yer almaktadır.

Test eşleme hakkında

Test eşleme, geliştiricilerin doğrudan Android kaynak ağacında göndermeden önce ve gönderdikten sonra test kuralları oluşturmasına ve test edilecek şube ve cihazlarla ilgili kararları test altyapısına bırakmasına olanak tanıyan Gerrit tabanlı bir yaklaşımdı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öndermeden önce testleri çalıştırmak için TEST_MAPPING dosyalarını kullanabilir. Test eşleştirme sayesinde, Android kaynak ağacında minimum düzeyde değişiklik yaparak aynı test grubunu göndermeden önce yapılan kontrollere ekleyebilirsiniz.

Aşağıdaki örneklere bakın:

• services.core için TEST_MAPPING'e göndermeden önce test ekleme

• İçe aktarma işlemlerini kullanarak tools/dexter için TEST_MAPPING'e göndermeden önce test ekleme

Test eşleme, test yürütme ve sonuç raporlama için Trade Federation (TF) test donanımından yararlanır.

Test gruplarını tanımlama

Grup eşleme testlerini test grubuyla test edin. Test grubunun adı herhangi bir dize olabilir. Örneğin, ön gönderme, değişiklikler doğrulanırken çalıştırılacak bir test grubunun adı olabilir. Gönderimden sonra, değişiklikler birleştirildikten sonra derlemeleri doğrulamak için kullanılan testler olabilir.

Paket oluşturma komut dosyası kuralları

Trade Federation test donanımının belirli bir derleme için test modüllerini çalıştırabilmesi için bu modüllerde Soong için bir test_suites veya Make için bu iki paketten birine ait bir LOCAL_COMPATIBILITY_SUITE ayarının olması gerekir:

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

Ö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 paketinde çalışabilmesi için:

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

• Cihazın belirli bir durumda (ör. root hazır) olduğunu varsaymamalısınız. Çoğu testin çalıştırılması için root ayrıcalığı gerekmez. Bir testin root gerektirmesi gerekiyorsa test, aşağıdaki örnekte olduğu gibi AndroidTest.xml içinde RootTargetPreparer ile bunu belirtmelidir:

  <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, testlerin söz konusu dizinde veya alt dizinlerinden herhangi birinde herhangi bir dosyaya dokunulduğunda yayın öncesi kontrollerde çalıştırılmasını sağlar.

Bir örneği takip edin

Aşağıda bir örnek TEST_MAPPING dosyası verilmiştir (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": "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 adlarıdır. Test grupları hakkında daha fazla bilgi için Test grupları tanımlama başlıklı makaleyi inceleyin.

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

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

file_patterns özelliği, herhangi bir kaynak kod dosyasının göreli yolunu (TEST_MAPPING dosyasını içeren dizine göre) eşleştirmek için normal ifade dizelerinin bir listesini ayarlamanıza olanak tanır. Örnekte, CtsWindowManagerDeviceTestCases testi yalnızca bir Java dosyası TEST_MAPPING dosyası veya bunun alt dizinlerinden biriyle aynı dizinde bulunan Window ya da Activity ile başladığında ön gönderme modunda çalışır. JSON dosyasında oldukları için ters eğik çizgilerin (\) kaçırılması gerekir.

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 aktarma işlemlerine olanak tanır. 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çenekleri içerir.

Belirli bir testte mevcut seçeneklerin tam listesini almak için şu komutu çalıştırın:

tradefed.sh run commandAndExit [test_module] --help

Seçeneklerin işleyiş şekli hakkında daha fazla bilgi için Tradefed'de seçeneklerin işlenmesi başlıklı makaleyi inceleyin.

Atest ile test yapma

Gönderme öncesi test kurallarını yerel olarak yürütmek için:

1. TEST_MAPPING dosyasını içeren dizine gidin.

2. Şu komutu çalıştırın:

   atest
   

Mevcut dizinin ve üst dizinlerinin TEST_MAPPING dosyalarında yapılandırılan tüm ön gönderme testleri çalıştırılır. Atest, göndermeden önce iki test (A ve B) bulup çalıştırır.

Bu, geçerli çalışma dizinindeki (CWD) ve üst dizinlerdeki TEST_MAPPINGdosyalarda göndermeden önce test çalıştırmanın en basit yoludur. Atest, CWD'deki ve tüm üst dizinlerindeki TEST_MAPPING dosyasını bulup kullanır.

Yapının kaynak kodu

Bu örnekte, kaynak ağaç genelinde 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

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

atest --test-mapping src/project_1

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

Bu komutu src_path içindeki TEST_MAPPING bölümünde (varsayılan olarak CWD) ve üst dizinlerinde 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 ana makineye göre yapılandırılmış ve cihaz gerektirmeyen testleri çalıştırmak için Atest için --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 yürütülür:

atest [--test-mapping] --host

Test gruplarını tanımlama

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 de 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 edin

Varsayılan olarak, Atest ile TEST_MAPPING'te test çalıştırıldığında yalnızca CWD (veya belirli dizin) ve üst dizinlerindeki TEST_MAPPING dosyasında yapılandırılan göndermeden önce testleri çalıştırılır. Alt dizinlerdeki tüm TEST_MAPPING dosyalarında test çalıştırmak isterseniz Atest'in bu testleri de dahil etmesini zorunlu kılmak 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 desteklemek için satır düzeyinde bir // biçimlendirme yorumu ekleyebilirsiniz. ATest ve Trade Federation, TEST_MAPPING öğesini yorum içermeyen geçerli bir JSON biçiminde ön işleme alır. JSON dosyasını temiz tutmak için yalnızca satır düzeyinde // biçiminde yorum desteklenir.

Örnek:

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