Gelişmiş test kurulumu

Android Studio'da test edin ve Komut satırından test, temel test yapılandırmalarını nasıl kullanabileceğinizi göstereceğim. Ancak, uygulamanız ve ileri düzey test gereksinimlerinin ortaya çıktığında, testinizi yapılandırmaya devam edin. Örneğin, şunları yapmak istiyorsunuz:

  • Araçlı testleri yalnızca belirli bir derleme varyantı için çalıştırın veya varyantı geçersiz kılın manifesto ayarlarında düzenleyebilirsiniz.
  • Testlerinizin çalıştırıldığı derleme türünü değiştirme veya Gradle'ı yapılandırma seçenekleri vardır.
  • Araçlı testlerinizi kendi test modüllerine çıkarın.
  • Sürekli Entegrasyon kurulumunuz kapsamında daha gelişmiş testler gerçekleştirin.

Bu sayfada, varsayılan değer ayarlandığında testlerinizi yapılandırmanın uygun olmadığından emin olun.

Derleme varyantı için araçlı test oluşturma

Projeniz yardımcı olacak araçlarlı testleri de bu kaynak kümelerine karşılık gelir. Böylece test kodunuz düzenli kalır ve yalnızca belirli bir derleme varyantı için geçerli olan testleri çalıştırmanızı sağlar.

Araçlı testleri bir derleme varyantına bağlamak için bu testleri kendi kaynak kümesi, şu konumda bulunur: src/androidTestVariantName

src/androidTest/ kaynak kümesindeki araçlı testler, oluşturun. "MyFlavor" için test APK'sı oluştururken varyantınızı Gradle, src/androidTest/ ve src/androidTestMyFlavor/ özelliklerini bir araya getiriyor kaynak kümeleridir.

Android Studio'da derleme varyantınız için bir test kaynağı grubu eklemek üzere şu adımları uygulayın:

  1. Proje penceresinde menüyü tıklayın ve Proje görünümünde yer alır.
  2. Uygun modül klasöründe src klasörünü sağ tıklayın ve Yeni > Dizin'e gidin.
  3. Dizin adı olarak "androidTestVariantName" yazın. Örneğin, "MyFlavor" adlı bir derleme varyantınız varsa dizin adını kullanın androidTestMyFlavor
  4. Tamam'ı tıklayın.
  5. Yeni dizini sağ tıklayın ve Yeni > Dizin'e gidin.
  6. "Java" yazın girin ve OK (Tamam) seçeneğini tıklayın.

Artık bu yeni kaynak kümesine test eklemek için yeni test ekleme adımlarını inceleyin. Hedef Dizini Seçin iletişim kutusunda, yeni varyant testi kaynak kümesi.

Aşağıdaki tabloda, enstrümantasyon testi dosyalarının uygulamanın kod kaynak kümelerine karşılık gelen kaynak kümelerinde bulunur:

Tablo 1. Uygulama kaynak kodu ve karşılık gelen enstrümantasyon test dosyaları

Uygulama sınıfına giden yol Eşleşen araç test sınıfına giden yol
src/main/java/Example.java src/androidTest/java/AndroidExampleTest.java
src/myFlavor/java/Example.java src/androidTestMyFlavor/java/AndroidExampleTest.java

Uygulama kaynak gruplarınızda olduğu gibi Gradle derlemesi de farklı test kaynağı kümelerindeki dosyaları geçersiz kılar. Bu durumda, androidTestMyFlavor kaynak kümesi geçersiz kılmalarında AndroidExampleTest.java dosya androidTest kaynak kümesindeki sürüm. Çünkü ürün aroması kaynağı grubu, ana kaynak grubuna göre önceliklidir.

Derleme varyantı seçicide farklı tatlar seçtiğinizde uygun androidTest klasörlerinin Android görünümünde kullanılan klasörleri göster:

MyFlavor varyantı seçildi ve androidTestMyFlavor klasörü gösteriliyor Android görünümünde
Şekil 1. MyFlavor varyant seçildi; "the" Android görünümünde androidTestMyFlavor klasörü gösterilir.

Farklı bir varyant aşağıdaki durumlarda androidTestMyFlavor klasörü gösterilmez seçili:

OtherFlavor varyantı seçildi ancak androidTestMyFlavor klasörü seçilmedi Android görünümünde gösteriliyor
Şekil 2. OtherFlavor varyant seçildi; "the" androidTestMyFlavor klasörü Android görünümünde gösterilmez.

Proje görünümünü kullanıyorsanız ancak görünüm aynıysa bu görünüm biraz farklı görünür şu ilke geçerlidir:

MyFlavor varyantı seçildi ve androidTestMyFlavor klasörü etkin Proje görünümünde
Şekil 3. MyFlavor varyant seçildi; "the" androidTestMyFlavor klasör, Proje görünümünde etkin.

Farklı bir varyant seçildiğinde androidTestMyFlavor klasörü kaldırılmaz görünür ancak etkin olarak gösterilmiyor:

OtherFlavor varyantı seçildi ancak androidTestMyFlavor klasörü seçilmedi Proje görünümünde etkin
Şekil 4. OtherFlavor varyant seçildi; "the" androidTestMyFlavor klasörü Proje görünümünde etkin değil.

Kaynak gruplarının nasıl birleştirildiği hakkında daha fazla bilgi edinmek için Kaynak kümeleri.

Araç manifest ayarlarını yapılandırın

Araçlı testler, kendi özel APK'sına sahip ayrı bir APK'da AndroidManifest.xml dosyası yükleyin. Gradle, test APK'nızı derlerken AndroidManifest.xml dosyasını otomatik olarak oluşturur ve yapılandırır şununla: <instrumentation> düğümü. Gradle'ın bu düğümü sizin için yapılandırmasının nedenlerinden biri de targetPackage özelliği, test edilen uygulamanın doğru paket adını belirtir.

Bu düğümle ilgili diğer ayarları değiştirmek için başka bir öğe oluşturun manifest dosyanızı yükleyin veya modül düzeyinizi yapılandırın build.gradle dosyası, gösterildiği gibi aşağıdaki kod örneğine bakalım. Seçeneklerin tam listesini şu adreste bulabilirsiniz: BaseFlavor API referansı.

Eski

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

Kotlin

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

Each product flavor you configure can override properties in the defaultConfig {} block. To learn more, go to Configure product flavors.

The properties in the snippet are:

Setting Description
testApplicationId Specifies the application ID for the test APK.
testInstrumentationRunner Specifies the fully qualified class name of the test instrumentation runner.
testHandleProfiling If set to true, enables the instrumentation class to start and stop profiling.
If set to false, profiling occurs the entire time the instrumentation class is running.
testFunctionalTest If set to true, indicates that the Android system should run the instrumentation class as a functional test.
The default value is false.

Change the test build type

By default, all instrumentation tests run against the debug build type. You can change this to another build type by using the testBuildType property in your module-level build.gradle file. For example, if you want to run your tests against your staging build type, edit the file as shown in the following snippet:

Groovy

android {
    ...
    testBuildType "staging"
}

Kotlin

android {
    ...
    testBuildType = "staging"
}

Gradle test seçeneklerini yapılandırın

Android Gradle eklentisi şunları yapmanıza olanak tanır: tüm testleriniz veya yalnızca bazıları için belirli seçenekler belirtebilirsiniz. modül düzeyindeki build.gradle dosyası için testOptions bloğunu kullanarak Gradle'ın tüm testlerinizi çalıştırma şeklini değiştiren seçenekleri belirtin:

Eski

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir "$rootDir/test-results"
    }
}

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

reportDir özelliği, Gradle'ın testi kaydettiği dizini değiştirir. raporlar. Gradle, test raporlarını varsayılan olarak path_to_your_project/module_name /build/outputs/reports/ dizini. $rootDir, yolu göreli olarak belirler kök dizinine dizin.

resultsDir özelliği, Gradle'ın testi kaydettiği dizini değiştirir. sonuç. Gradle, test sonuçlarını varsayılan olarak path_to_your_project/module_name /build/outputs/test-results/ dizini. $rootDir, yolu göreli olarak belirler kök dizinine dizin.

Yalnızca yerel birim testlerine ilişkin seçenekleri belirtmek için unitTests testOptions içinde engellenecek.

Eski

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

Kotlin

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues = true

            all {
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                 if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

Varsayılan olarak, yerel birim testleri kod her yapıldığında bir istisna atar Android platformu API'lerine erişmeye çalışırsanız örnek Android bağımlılıkları veya bir test çerçevesi kullanılarak oluşturulan Örnek. Ancak returnDefaultValues özelliğini etkinleştirebilirsiniz. test, platform API'lerine erişirken yerine boş veya sıfır değerini döndürür istisnai bir durum olabilir.

all bloğu, Gradle'ın çalışma şeklini kontrol etme seçeneklerini içerir. yerel birim testleri. Belirtebileceğiniz tüm seçeneklerin listesi için Gradle'ın referans belgeleri.

jvmArgs özelliği, test JVM'leri için JVM bağımsız değişkenlerini ayarlar.

Ayrıca, görev adını işaretleyerek seçenekleri yalnızca belirlediğiniz testlere uygulayabilirsiniz belirtin. Örnek snippet'te debug özelliği true olarak ayarlanmıştır ancak yalnızca testDebugUnitTest görevi için.

Araçlı testler için ayrı test modülleri kullanma

Araçlı testler için özel bir modüle sahip olmak istiyorsanız, kalan kısmını testlerinizden çıkarmak yerine, ayrı bir test modülü oluşturun derlemesini kitaplık modülüne benzer şekilde yapılandıracaktır.

Test modülü oluşturmak için aşağıdaki adımları uygulayın:

  1. Kitaplık modülü oluşturun.
  2. Modül düzeyindeki build.gradle dosyasına com.android.test eklentisidir.com.android.library
  3. Projeyi Senkronize Et'i tıklayın.

Test modülünüzü oluşturduktan sonra, test kodunuzu ana veya varyant kaynak grubu (örneğin, src/main/java veya src/variant/java) tıklayın. Uygulama modülünüz bu aromaları test modülünüzde yeniden oluşturabilirsiniz. Varyanta duyarlı bağımlılığı kullanma yönetim, test modülü, hedef modüldeki eşleştirme aromasını test etmeye çalışır.

Test modülleri, varsayılan olarak yalnızca bir hata ayıklama varyantı içerir ve bu varyantları test eder. Ancak, test edilen uygulama projesine uygun yeni derleme türleri oluşturabilirsiniz. To test modülü, hata ayıklamayı değil farklı bir derleme türünü test etmek için Test projesinde hata ayıklama varyantını devre dışı bırakmak için VariantFilter:

Eski

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

Kotlin

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

Bir test modülünün yalnızca belirli tatları veya belirli bir matchingFallbacks uygulamasını kullanabilirsiniz. özelliğini kullanmanızı öneririz. Bu ayrıca, test modülünün kendisi için yapılandırma zorunluluğunu ortadan kaldırıyor.