Bu sayfa, Cloud Translation API ile çevrilmiştir.

Eşlemeyi test et

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şlayacağınıza ilişkin bir açıklamadır.

Test eşleme hakkında

Test eşleme, geliştiricilerin doğrudan Android kaynak ağacında yayın öncesi ve sonrası test kuralları oluşturmasına, test edilecek dallar ve cihazlara ilişkin 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ştirilebilen TEST_MAPPING adlı JSON dosyalarıdır.

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

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

services.core için TEST_MAPPING öğesine gönderme öncesi testleri ekleme

Araçlar/dexter için içe aktarma işlemlerini TEST_MAPPING öğesine gönderme öncesi testleri ekleme

Test eşleme, testlerin yürütülmesi ve sonuçların raporlanması için Ticari Federasyon (TF) Test Bandı'nı kullanır.

Test gruplarını tanımlayın

Eşleme grubu testlerini bir test grubu aracılığıyla test edin. Test grubunun adı herhangi bir dize olabilir. Örneğin, presubmit (gönderme öncesi) işlevi, değişiklikler doğrulanırken çalıştırılacak bir grup test olabilir. Değişiklikler birleştirildikten sonra derlemeleri doğrulamak için postsubmit testleri kullanılabilir.

Paket derleme komut dosyası kuralları

Trade Federation Test Harness'ın belirli bir derleme için test eşlemenin test modüllerini çalıştırabilmesi amacıyla bu modüllerde Soong veya LOCAL_COMPATIBILITY_SUITE için ayarlanmış test_suites olması gerekir.

genel testler - Cihaza özel işlevlere bağlı olmayan testler (çoğu cihazda bulunmayan satıcıya özgü donanım gibi). Çoğu test, tek bir ABI'ya veya bit hızına ya da HWASan gibi donanım özelliklerine (her ABI için ayrı bir test_suite hedefi vardır) özel olsa bile ve bir cihazda çalıştırılmaları gerekse bile genel test paketinde yer almalıdır.
cihaz-testleri - Cihaza özel işlevlere bağlı testler. Genellikle bu testler vendor/ altında bulunur. "Cihaza özgü" ifadesi diğer cihazların sahip olabileceği veya olmayabileceği ABI veya SoC işlevleri yerine yalnızca bir cihaza özgü işlevlerle ilgili değildir. Bu, JUnit'in her bit için GTest yerel testleriyle aynı şekilde (ABI'ye özel olsa bile genellikle general-tests olması gerekir) testleri için geçerlidir.

Ö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

Test paketi içinde bir testin çalıştırılması için test:

derleme sağlayıcısı olmamalıdır.
temizlenmesi gerekir (örneğin, test sırasında oluşturulan geçici dosyaları silerek).
sistem ayarlarını varsayılan veya orijinal değere getirin.
olduğu gibi, bir cihazın köküne hazır olduğunu varsaymamalıdır. Çoğu testin çalışması için kök ayrıcalığı gerekmez. Bir test, kök gerektirmesi gerekiyorsa aşağıdaki örnekte olduğu gibi bunu AndroidTest.xml içinde bir 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 dizinde veya bunun alt dizinlerinden herhangi birinde herhangi bir dosyaya dokunulduğunda, testlerin yayın öncesi kontrollerinde çalıştırılmasını sağlar.

Bir örneği takip edin

Aşağıda örnek bir TEST_MAPPING dosyası verilmiştir (bu dosya 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"
    }
  ]
}

Özellikleri belirleyin

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 Ticari Federasyon entegrasyon testi adı (test XML dosyasının kaynak yolu, ör. uiautomator/uiautomator-demo), name özelliğinin değerinde ayarlanabilir. 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 buradaki include-filter gibi seçenekleri kullanabilirsiniz. Bkz. (dahil etme filtresi örnek kullanımı).

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 (yanlış) değeridir, yani testin çalışması için bir cihazın olması gerekir. Desteklenen test türleri, GTest ikili programları için HostGTest ve JUnit testleri için HostTest'tir.

file_patterns özelliği herhangi bir kaynak kodu dosyasının göreli yolunu (TEST_MAPPING dosyasını içeren dizinle) eşleştirmek için bir normal ifade dizeleri listesi ayarlamanıza olanak tanır. Yukarıdaki örnekte CtsWindowManagerDeviceTestCases testi yalnızca TEST_MAPPING dosyasının aynı dizininde veya alt dizinlerinden birinde bulunan Pencere ya da Etkinlik ile başlayan herhangi bir Java dosyası değiştirildiğinde ön gönderme modunda çalışır. Ters eğik çizgiler, bir JSON dosyasında olduğu için kod dışına alınmalıdır.

Imports özelliği, içeriği kopyalamadan diğer TEST_MAPPING dosyalarına testleri 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 aktarma işlemlerine olanak tanır. Bu, iki TEST_MAPPING dosyasının birbirini içe aktarabileceği ve Test eşlemesinin dahil edilen testleri düzgün bir şekilde birleştirebildiğ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 Opsiyon Kullanımı bölümüne bakın.

Atest ile test çalıştırma

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

TEST_MAPPING dosyasını içeren dizine gidin.
Ş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, yayın öncesi için iki test (A ve B) bulup çalıştırır.

Bu, mevcut çalışma dizinindeki (CWD) ve üst dizinlerdeki TEST_MAPPING dosyalarında gönderme öncesi 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ırın

Aşağıdaki örnekte, TEST_MAPPING dosyalarının kaynak ağaç genelinde nasıl yapılandırılabileceği 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 üzere bir 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ır

Bu komutu, src_path (varsayılan olarak CWD) içinde ve üst dizinlerinde TEST_MAPPING bölümünde tanımlanan yayın 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 cihaz gerektirmeyen ana makineye göre yapılandırılmış testleri çalıştırmak üzere Atest için --host seçeneğini kullanabilirsiniz. Bu seçenek kullanılmadığında, Atest her iki testi de (cihaz gerektirenler ve ana makinede çalışan testler) çalıştırır ve cihaz gerektirmez. Testler iki ayrı süitte yürütülecektir.

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.

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

atest --test-mapping src/project_1:all

Alt dizinleri dahil et

Varsayılan olarak, TEST_MAPPING içinde Atest ile test çalıştırıldığında, yalnızca CWD'deki (veya belirtilen dizindeki) TEST_MAPPING dosyasında ve üst dizinlerindeki TEST_MAPPING dosyasında yapılandırılan yayın öncesi testleri çalıştırılır. Alt dizinlerdeki tüm TEST_MAPPING dosyalarında test çalıştırmak istiyorsanız, onaylamayı bu testleri de dahil etmeye zorlamak için --include-subdir seçeneğini kullanın.

atest --include-subdir

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

Satır düzeyinde yorum desteklenir

TEST_MAPPING dosyasını aşağıdaki ayarla ilgili açıklamayla birlikte geliştirmek için satır düzeyinde // biçiminde bir yorum ekleyebilirsiniz. ATest ve Ticaret Federasyonu, TEST_MAPPING öğesini yorum içermeyen geçerli bir JSON biçiminde önceden işler. JSON dosyasının temiz ve kolay okunması 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"
    }
  ]
}