Gelişmiş test kurulumu

Android Studio'da test etme ve Komut satırından test etme başlıklı makalelerde, temel test yapılandırmalarının nasıl ayarlanacağı ve çalıştırılacağı açıklanmaktadır. Ancak uygulamanız ve test gereksinimleri daha gelişmiş hale geldiğinde test yapılandırmalarınızı daha fazla uyarlamanız gerekebilir. Örneğin, aşağıdakileri yapmak istediğinizde gelişmiş test kurulumu gerekebilir:

• Yalnızca belirli bir derleme varyantı için enstrümanlı testler çalıştırın veya manifest ayarlarını geçersiz kılın.
• Testlerinizin üzerinde çalıştırıldığı derleme türünü değiştirin veya Gradle seçeneklerini yapılandırın.
• Enstrümanlı testlerinizi kendi test modüllerine ayırın.
• Sürekli entegrasyon kurulumunuzun bir parçası olarak daha gelişmiş testler yapın.

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

Bir derleme değişkeni için araçlı test oluşturma

Projeniz benzersiz kaynak kümeleri içeren derleme varyantları içeriyorsa bu kaynak kümelerine karşılık gelen enstrümanlı testler eklemek isteyebilirsiniz. Bu sayede test kodunuz düzenli kalır ve yalnızca belirli bir derleme değişkeni için geçerli olan testleri çalıştırabilirsiniz.

Enstrümantasyonlu testleri bir derleme değişkenine bağlamak için testleri kendi kaynak grubuna yerleştirin. Kaynak grubu src/androidTestVariantName konumunda bulunur.

src/androidTest/ kaynak grubundaki enstrümanlı testler tüm derleme değişkenleri tarafından paylaşılır. Uygulamanızın "MyFlavor" varyantı için bir test APK'sı oluştururken Gradle, src/androidTest/ ve src/androidTestMyFlavor/ kaynak kümelerini birleştirir.

Android Studio'da derleme değişkeniniz için bir test kaynak 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. Uygun 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" girin. Örneğin, "MyFlavor" adlı bir derleme değişkeniniz varsa dizin adını androidTestMyFlavor olarak 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"yı girip Tamam'ı tıklayın.

Artık yeni test ekleme adımlarını uygulayarak bu yeni kaynak grubuna test ekleyebilirsiniz. Hedef dizini seçin iletişim kutusuna ulaştığınızda yeni varyant testi kaynak grubunu seçin.

Aşağıdaki tabloda, enstrümantasyon testi dosyalarının uygulamanın kod kaynak kümelerine karşılık gelen kaynak kümelerinde nasıl bulunabileceğine dair bir örnek gösterilmektedir:

Tablo 1. Uygulama kaynak kodu ve ilgili enstrümantasyon testi dosyaları

Gradle derlemesi, uygulama kaynak kümelerinizde olduğu gibi farklı test kaynak kümelerindeki dosyaları birleştirir ve üzerine yazar. Bu durumda, androidTestMyFlavor kaynak grubundaki AndroidExampleTest.kt dosyası, androidTest kaynak grubundaki sürümü geçersiz kılar. Bunun nedeni, ürün türü kaynak grubunun ana kaynak grubuna göre önceliğe sahip olmasıdır.

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

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

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

Farklı bir varyant seçildiğinde androidTestMyFlavor klasörü görünmeye devam eder ancak etkin olarak gösterilmez:

Kaynak kümelerinin nasıl birleştirildiği hakkında daha fazla bilgi için Kaynak kümeleri başlıklı makaleyi inceleyin.

Enstrümantasyon manifesti ayarlarını yapılandırma

Enstrümanlı testler, kendi AndroidManifest.xml dosyasıyla ayrı bir APK'da oluşturulur. Gradle, test APK'nızı oluştururken AndroidManifest.xml dosyasını otomatik olarak oluşturur ve <instrumentation> düğümüyle yapılandırır. Gradle'ın bu düğümü sizin için yapılandırmasının nedenlerinden biri, targetPackage özelliğinin, test edilen uygulamanın doğru paket adını belirtmesini sağlamaktır.

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

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

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

Yapılandırdığınız her ürün türü, defaultConfig {} bloğundaki özellikleri geçersiz kılabilir. Daha fazla bilgi için Ürün çeşitlerini yapılandırma başlıklı makaleyi inceleyin.

Snippet'teki özellikler şunlardır:

Test derlemesi türünü değiştirme

Varsayılan olarak tüm enstrümantasyon testleri debug derleme türüne göre çalıştırılır. Modül düzeyindeki build.gradle dosyanızda testBuildType özelliğini kullanarak bunu başka bir derleme türüyle değiştirebilirsiniz. Örneğin, testlerinizi staging derleme türünüze göre çalıştırmak istiyorsanız dosyayı aşağıdaki snippet'te gösterildiği gibi düzenleyin:

android {
    ...
    testBuildType = "staging"
}

android {
    ...
    testBuildType "staging"
}

Gradle test seçeneklerini yapılandırma

Android Gradle eklentisi, testlerinizin tümü veya yalnızca bazıları için belirli seçenekler belirtmenize olanak tanır. 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 bloğunu kullanın:

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

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 ayarlar.

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 ayarlar.

Yalnızca yerel birim testleriyle ilgili seçenekleri belirtmek için testOptions içindeki unitTests bloğunu yapılandırın.

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

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

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

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

Varsayılan olarak, test ettiğiniz kod Android platform API'lerine erişmeye çalıştığında yerel birim testleri bir istisna oluşturur. Bu durum, Android bağımlılıklarını kendiniz veya Mockito gibi bir test çerçevesiyle taklit etmediğiniz sürece geçerlidir. Ancak, platform API'lerine erişirken bir istisna oluşturmak yerine testin boş veya sıfır döndürmesi için returnDefaultValues özelliğini etkinleştirebilirsiniz.

all bloğu, Gradle'ın yerel birim testlerini nasıl yürüteceğini kontrol etme seçeneklerini kapsar. Belirtebileceğiniz tüm seçeneklerin listesi için Gradle'ın referans dokümanlarını inceleyin.

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

Yalnızca belirttiğiniz testlere seçenek uygulamak için görev adını da kontrol edebilirsiniz. Örnek snippet'te debug özelliği true olarak ayarlanmıştır ancak yalnızca testDebugUnitTest görevi için.

Enstrümanlı testler için ayrı test modülleri kullanma

Kodunuzun geri kalanını testlerinizden izole etmek için izleme araçları eklenmiş testlere özel bir modül oluşturmak istiyorsanız ayrı bir test modülü oluşturun ve derlemesini bir kitaplık modülünün derlemesine benzer şekilde yapılandırın.

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 (ör. src/main/kotlin+java veya src/variant/kotlin+java) ekleyebilirsiniz. Uygulama modülünüzde birden fazla ürün türü tanımlanmışsa bu türleri test modülünüzde yeniden oluşturabilirsiniz. Varyant farkındalığına sahip bağımlılık yönetimi kullanıldığında, test modülü, hedef modüldeki eşleşen türü test etmeye çalışır.

Test modülleri varsayılan olarak yalnızca bir hata ayıklama varyantı içerir ve bunu test eder. Ancak, test edilen uygulama projesiyle eşleşen yeni derleme türleri oluşturabilirsiniz. Test modülünün hata ayıklama sürümü yerine farklı bir derleme türünü test etmesini sağlamak için test projesinde hata ayıklama varyantını devre dışı bırakmak üzere VariantFilter kullanın.

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

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

Bir test modülünün yalnızca belirli tatları veya uygulama derleme türlerini hedeflemesini istiyorsanız yalnızca test etmek istediğiniz varyantları hedeflemek için matchingFallbacks özelliğini kullanabilirsiniz. Bu sayede, test modülünün bu varyantları kendisi için yapılandırması da önlenir.