Gelişmiş test kurulumu

Android Studio'da test etme ve komut satırından test etme, temel test yapılandırmalarının nasıl ayarlanıp çalıştırılacağını açıklar. Ancak uygulamanız ve test gereksinimleri daha gelişmiş hale geldiğinde test yapılandırmalarınızı daha da uyarlamanız gerekebilir. Örneğin, aşağıdakileri yapmak istediğinizde gelişmiş test kurulumuna ihtiyacınız olabilir:

• Araçlı testleri yalnızca belirli bir derleme varyantı için çalıştırın veya manifest ayarlarını geçersiz kılın.
• Testlerinizin çalıştırıldığı derleme türünü değiştirin veya Gradle seçeneklerini yapılandırın.
• Cihazlı testlerinizi kendi test modüllerine çıkarın.
• Sürekli Entegrasyon kurulumunuzun bir parçası olarak daha gelişmiş testler gerçekleştirin.

Bu sayfada, varsayılan ayarlar ihtiyaçlarınıza uygun olmadığında testlerinizi yapılandırmanın çeşitli yolları açıklanmaktadır.

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

Projenizde benzersiz kaynak gruplarına sahip varyantlar oluşturma varsa bu kaynak gruplarına karşılık gelen araçlı testleri dahil etmek isteyebilirsiniz. Bu, test kodunuzun düzenli kalmasını sağlar 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 bunları src/androidTestVariantName adresinde bulunan kendi kaynak gruplarına yerleştirin.

src/androidTest/ kaynak grubundaki desteklenen testler tüm derleme varyantları tarafından paylaşılır. Gradle, uygulamanızın "MyFlavor" varyantı için bir test APK'sı oluştururken src/androidTest/ ve src/androidTestMyFlavor/ kaynak gruplarını birleştirir.

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

1. Proje penceresinde menüyü tıklayın ve Proje görünümünü seçin.
2. İlgili modül klasöründe src klasörünü sağ tıklayın ve Yeni > Dizin'i tıklayın.
3. Dizin adı olarak "androidTestVariantName" yazın. Örneğin, "MyFlavor" adlı bir derleme varyantınız varsa androidTestMyFlavor dizin adını kullanın.
4. Tamam'ı tıklayın.
5. Yeni dizini sağ tıklayın ve Yeni > Dizin'i seçin.
6. Dizin adı olarak "java" yazın ve OK (Tamam) düğmesini tıklayın.

Artık yeni test ekleme adımlarını uygulayarak bu yeni kaynak kümesine test ekleyebilirsiniz. Hedef Dizini Seçin iletişim kutusunda, yeni varyant test kaynağı grubunu seçin.

Aşağıdaki tabloda, araç testi dosyalarının uygulamanın kod kaynağı gruplarına karşılık gelen kaynak kümelerinde nasıl olabileceğine dair bir örnek gösterilmektedir:

Tablo 1. Uygulama kaynak kodu ve ilgili araç test dosyaları

Uygulama sınıfı yolu	Eşleşen araç testi sınıfı yolu
src/main/java/Example.java	src/androidTest/java/AndroidExampleTest.java
src/myFlavor/java/Example.java	src/androidTestMyFlavor/java/AndroidExampleTest.java

Uygulama kaynağı gruplarınızda olduğu gibi, Gradle derlemesi de farklı test kaynağı gruplarındaki dosyaları birleştirir ve geçersiz kılar. Bu durumda androidTestMyFlavor kaynak grubundaki AndroidExampleTest.java dosyası, androidTest kaynak grubundaki sürümü geçersiz kılar. Bunun nedeni, ürün aroması kaynağı grubunun ana kaynak grubuna göre öncelikli olmasıdır.

Derleme varyantları seçicide farklı aromalar seçtiğinizde, kullanılan klasörleri göstermek için Android görünümünde uygun androidTest klasörleri gösterilir:

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

Farklı bir varyant seçildiğinde androidTestMyFlavor klasörü gösterilmez:

Şekil 2. OtherFlavor varyantı seçildi. androidTestMyFlavor klasörü Android görünümünde gösterilmez.

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

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

Farklı bir varyant seçildiğinde androidTestMyFlavor klasörü hâlâ görünür ancak etkin olarak gösterilmez:

Şekil 4. OtherFlavor varyant seçildi. 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 için Kaynak grupları bölümüne bakın.

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

Araçlı testler, kendi AndroidManifest.xml dosyası olan ayrı bir APK'da yerleşik olarak bulunur. Gradle, test APK'nızı derlerken AndroidManifest.xml dosyasını otomatik olarak oluşturur ve <instrumentation> düğümüyle yapılandırır. Gradle'ın sizin için bu düğümü yapılandırmasının nedenlerinden biri, targetPackage özelliğinin test edilen uygulamanın doğru paket adını belirttiğinden emin olmaktır.

Bu düğümün diğer ayarlarını değiştirmek için test kaynağı grubunda başka bir manifest dosyası oluşturun veya modül düzeyindeki build.gradle dosyanızı aşağıdaki kod örneğinde gösterildiği gibi yapılandırın. Seçeneklerin tam listesini BaseFlavor API referansında bulabilirsiniz.

Eskitme

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

Android Gradle eklentisi, testlerinizin tümü veya bazıları için belirli seçenekleri belirtmenizi sağlar. Modül düzeyindeki build.gradle dosyasında, Gradle'ın tüm testlerinizi çalıştırma şeklini değiştiren seçenekleri belirtmek için testOptions blokunu kullanın:

Eskitme

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 test raporlarını kaydettiği dizini değiştirir. Gradle, varsayılan olarak test raporlarını path_to_your_project/module_name /build/outputs/reports/ dizinine kaydeder. $rootDir, yolu geçerli projenin kök dizinine göre belirler.

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

Yalnızca yerel birim testlerine yönelik seçenekleri belirtmek için testOptions içinde unitTests bloğunu yapılandırın.

Eskitme

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")
                }
                ...
            }
        }
    }
}

Test ettiğiniz kod Android platformu API'lerine erişmeye çalıştığı her seferde yerel birim testleri varsayılan olarak bir istisna oluşturur. Bunun için Android bağımlılıklarıyla dalga geçme konusunda kendiniz veya Mockito gibi bir test çerçevesi kullanmanız gerekir. Bununla birlikte, returnDefaultValues özelliğini etkinleştirerek testin, platform API'lerine erişirken istisna göndermek yerine boş veya sıfır değerini döndürmesini sağlayabilirsiniz.

all bloğu, Gradle'ın yerel birim testlerini nasıl yürüttüğünü kontrol etme seçeneklerini içerir. Belirtebileceğiniz tüm seçeneklerin listesi için Gradle'ın referans belgelerini okuyun.

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

Seçenekleri yalnızca belirttiğiniz testlere uygulamak için görev adını da işaretleyebilirsiniz. Örnek snippet'te debug özelliği, yalnızca testDebugUnitTest görevi için true olarak ayarlanmıştır.

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

Araçlı testler için özel bir modüle sahip olmak istiyorsanız kodunuzun geri kalanını testlerinizden ayırmak için ayrı bir test modülü oluşturun ve derlemesini kitaplık modülüne benzer şekilde yapılandırın.

Bir 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ında, com.android.library yerine com.android.test eklentisini uygulayın.
3. Projeyi Senkronize Et'i tıklayın.

Test modülünüzü oluşturduktan sonra test kodunuzu ana veya varyant kaynak grubuna (örneğin, src/main/java veya src/variant/java) ekleyebilirsiniz. Uygulama modülünüz birden çok ürün aroması tanımlıyorsa bu aromaları test modülünüzde yeniden oluşturabilirsiniz. Test modülü, varyanta duyarlı bağımlılık yönetimini kullanarak hedef modüldeki eşleşen aromayı test etmeye çalışır.

Varsayılan olarak test modülleri, yalnızca bir hata ayıklama varyantı içerir ve test edilir. Ancak test edilen uygulama projesine uygun yeni derleme türleri oluşturabilirsiniz. Test modülünün hata ayıklamasını değil, farklı derleme türünü test etmesini istiyorsanız aşağıdaki şekilde test projesinde hata ayıklama varyantını devre dışı bırakmak için VariantFilter öğesini kullanın:

Eskitme

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 aromaları veya uygulama derleme türlerini hedeflemesini isterseniz yalnızca test etmek istediğiniz varyantları hedeflemek için matchingFallbacks özelliğini kullanabilirsiniz. Bu sayede, test modülünün bu varyantları kendi başına yapılandırmak zorunda kalmasını da önlersiniz.