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 ileri seviyelere 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 ihtiyaç duyabilirsiniz:
- 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.
- Donanımlı 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 izlemeli testler eklemek isteyebilirsiniz. Böylece test kodunuz düzenli kalır ve yalnızca belirli bir derleme varyantı için geçerli olan testleri çalıştırabilirsiniz.
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 kümesindeki araçlı 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 bir test kaynağı grubu eklemek üzere şu adımları uygulayın:
- Proje penceresinde menüyü tıklayın ve Proje görünümünü seçin.
- İlgili modül klasöründe src klasörünü sağ tıklayın ve Yeni > Dizin'i tıklayın.
- Dizin adı için "androidTestVariantName" yazın. Örneğin, "MyFlavor" adlı bir derleme varyantınız varsa
androidTestMyFlavor
dizin adını kullanın. - Tamam'ı tıklayın.
- Yeni dizini sağ tıklayın ve Yeni > Dizin'i seçin.
- 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 kutusuna ulaştığınızda 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 bulunabileceğine dair bir örnek gösterilmektedir:
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ı çeşitler seçtiğinizde, kullanılan klasörleri göstermek için Android görünümünde uygun androidTest
klasörleri görüntülenir:
Farklı bir varyant seçildiğinde androidTestMyFlavor
klasörü gösterilmez:
Proje görünümünü kullanıyorsanız bu durum biraz farklı görünür ancak aynı ilke geçerlidir:
Farklı bir varyant seçildiğinde androidTestMyFlavor
klasörü görünür ancak etkin olarak gösterilmez:
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.
Modern
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, testlerinizin tümü veya bazıları için belirli seçenekleri 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
blokunu kullanın:
Modern
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. Varsayılan olarak Gradle, 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. Varsayılan olarak Gradle, 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çinde unitTests
bloğunu yapılandırın.
Modern
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, test ettiğiniz kod Android platformu API'lerine erişmeye çalıştığında yerel birim testleri istisna atar. Bunun için Android bağımlılıklarıyla ilgili deneme yapmanız veya Moockito gibi bir test çerçevesi kullanmanız gerekir. Bununla birlikte, returnDefaultValues
özelliğini etkinleştirerek test, platform API'lerine erişirken istisna göndermek yerine null veya sıfır değerini döndürür.
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 true
olarak ayarlanmıştır ancak yalnızca testDebugUnitTest
görevi için 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 izole etmek için ayrı bir test modülü oluşturun ve derlemesini bir 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:
- Kitaplık modülü oluşturun.
- Modül düzeyindeki
build.gradle
dosyasında,com.android.library
yerinecom.android.test
eklentisini uygulayın. - 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 fazla ürün çeşidi tanımlıyorsa bu aromaları test modülünüzde yeniden oluşturabilirsiniz.
Test modülü, varyant duyarlı bağımlılık yönetimini kullanarak hedef modüldeki eşleşen türü 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 projesiyle eşleşecek yeni derleme türleri oluşturabilirsiniz. Test modülü testini, hata ayıklama türü yerine farklı bir derleme türünde yapmak için VariantFilter
kullanarak test projesindeki hata ayıklama varyantını devre dışı bırakın.
Modern
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 çeşitleri veya 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ırması da önlenir.