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:
services.coreiçinTEST_MAPPING'ye gönderme öncesi testler eklemeİçe aktarmaları kullanarak
tools/dexteriçinTEST_MAPPINGöğesine gönderme öncesi testler ekleme
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ı birtest_suiteshedefi vardır) ve cihazda çalışması gerekse bilegeneral-testspaketinde olmalıdır.device-tests, cihaza özel özelliklere bağlı testler içindir. Bu testler genelliklevendor/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 genelliklegeneral-testsolarak 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.xmliçindeRootTargetPreparerile 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:
TEST_MAPPINGdosyasını içeren dizine gidin.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"
}
]
}