Eşleştirmeyi Test Et

Bu, Test Eşleme'nin kısa bir tanıtımı 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 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 presubmit testler TEST_MAPPING dosyalarını kullanabilirsiniz. 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önderim testleri ekleyin

Deney Haritalama dayanır Ticaret Federasyonu (TF) Testi Demeti testleri yürütülmesi ve sonuçların raporlanması için.

Test gruplarını tanımlama

Deney eşleme grupları, bir test grubu ile test eder. Bir test grubunun adı herhangi bir dize olabilir. Örneğin, presubmit değişiklikleri doğrularken çalıştırmak için bir çok test grubu için olabilir. Ve postsubmit testleri değişiklikler birleştirilir sonra inşa doğrulamak için kullanılabilir.

Paketleme oluşturma komut dosyası kuralları

İçin Amacıyla Ticaret Federasyonu Testi Koşum verilen bir yapı için test Haritalama test modülleri çalıştırmak için, bu modüller için test_suite ayarlanmış olmalıdır Soong bu iki suit birine Make için veya LOCAL_COMPATIBILITY_SUITE seti:

  • Genel-Testler - cihaza özgü özelliklerle bağlı olmayan testler. Çoğu test, desteklenen tüm ABI'lerde (32'ye karşı 64) ikili dosyaları (yerel testler için) içeren test_suites hedefinde oluşturulabileceğinden, genel testler paketinde olmalıdır.
  • Cihaza testler - testleri, cihaza özgü özelliklerine bağlıdır bazı cihaz hedeflere sadece Runnable veya yalnızca sadece belirli cihaz hedefleri üzerine inşa edilebilir. Bu, testin yerel bir test mi yoksa JUnit testi mi olduğu doğrudur.

Örnekler:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Testleri bir test paketinde çalışacak şekilde yapılandırma

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, bunu bir RootTargetPreparer ile belirtmelidir, örneğin:

<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 bir örnek TEST_MAPPING dosyası (desteklenen JSON biçiminde ancak yorumlarla var):

{
  "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 native test with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side native test.
    {
      "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 test grubu isimleridir. Bkz test gruplarını tanımlama testi grupları hakkında daha fazla bilgi için bkz.

Test modülü veya Ticaret Federasyonu entegrasyon test adı (test XML dosyasına kaynak yolu, örneğin, adı uiautomator / uiautomator-demo ) değerinde ayarlanabilir name özniteliği. Sınıf kullanamaz adı alanını Not name veya test yöntemi name . Çalıştırmak için testler daraltmak için, gibi seçenekleri kullanabilirsiniz include-filter burada. (Bkz içerir filtre örnek kullanım ).

Bir testin konak ayar testi ana bilgisayar veya değil üzerinde çalışan bir deviceless testtir olmadığını gösterir. Varsayılan değer, test anlam çalıştırmak için bir cihaz yanlış gerektirir. Desteklenen deney türleri HostGTest yerli testler ve için HostTest JUnit testleri için.

File_patterns ayrıntının (TEST_MAPPING dosyasını içeren dizinine göre) herhangi bir kaynak kodu dosyası göreli yolunu eşleştirmek için düzenli ifade dizeleri listesini ayarlamanızı sağlar. Yukarıdaki örnekte, deney CtsWindowManagerDeviceTestCases TEST_MAPPING dosya veya alt dizinleri herhangi birinin aynı dizinde var olan Window veya Aktivite ile herhangi java dosya başlar, değiştirildiğinde yalnızca presubmit çalışır. Bir JSON dosyasında oldukları için ters eğik çizgilerden \ kaçınılması gerekir.

İthalat nitelik içerik kopyalama olmadan, diğer TEST_MAPPING dosyalarında testleri eklemenize olanak verir. İç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.

Seçenekleri nitelik 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

Bakınız Handling TradeFed Seçeneği nasıl seçenekleri çalışmaları hakkında daha fazla ayrıntı için.

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

İçeriği src/TEST_MAPPING :

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

İçeriği src/project_1/TEST_MAPPING :

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

İçeriği src/project_2/TEST_MAPPING :

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

Hedef dizinleri belirtme

Testleri o dizindeki TEST_MAPPING dosyalarında ç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

Ayrıca TEST_MAPPING tanımlanan postsubmit testi kurallarını çalıştırmak için bu komutu kullanabilirsiniz src_path (CWD'sindeki için varsayılan) ve üst dizinleri:

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

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

Hiçbir cihaz gerektiren konak karşı yapılandırılmış sadece koşmak testlere ATEST seçeneği --host kullanabilirsiniz. Bu seçenek olmadan Atest, cihaz gerektirenler ve ana bilgisayarda ç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

Test gruplarını Atest komutunda 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 testi (A, B, C, X) çalıştırır:

atest --test-mapping src/project_1:all

Alt dizinler dahil

Varsayılan olarak, testlerin Atest ile TEST_MAPPING içinde çalıştırılması, yalnızca CWD'deki (veya verilen dizindeki) ve onun üst dizinlerindeki TEST_MAPPING dosyasında yapılandırılan teslim öncesi testleri çalıştıracaktı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.

Satır düzeyinde yorum desteklenir

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.

Örnek:

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